Announcement

Collapse
No announcement yet.

SphinUX OS Claims To Be ~150% Faster Than GNU/Linux

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Yes. Still very unprofessional.

    I have looked around a bit but I have not found anything that indicates it is not linux. All the loaded modules (lsmod) seem to be vanilla linux modules (modinfo). Only in /proc/sys/kernel/version it says "#1 SMP LX-arch 1.0.12-1". That's not really enough to convince me. dmesg and /var/log/syslog look pretty much like linux. There is something in /dist/boot/ltspdk/.temp/. Is it different from a linux kernel? If so, is it actually loaded?

    Comment


    • #47
      Originally posted by ChrisXY View Post
      Yes. Still very unprofessional.

      I have looked around a bit but I have not found anything that indicates it is not linux. All the loaded modules (lsmod) seem to be vanilla linux modules (modinfo). Only in /proc/sys/kernel/version it says "#1 SMP LX-arch 1.0.12-1". That's not really enough to convince me. dmesg and /var/log/syslog look pretty much like linux. There is something in /dist/boot/ltspdk/.temp/. Is it different from a linux kernel? If so, is it actually loaded?
      As far as I can see /dist is a whole lot of nothing. All the binaries segfault if you run them and the system boots perfectly fine if the whole directory is removed.

      Comment


      • #48
        The distro ships with quite a few penetration tools. Not sure what they are for...

        EDIT: bkhive and samdump2 are included. Those tools dump the password hashes from the SAM registry hive on Windows partitions.

        Comment


        • #49
          TL;DR: There's a script that sends logs, hardware information, and takes a screenshot of the active Xorg session to http://www.sphinux.org/bug_report.php
          • /sbin/au
            • Grabs MAC addresses of all network interfaces
          • /sbin/auther
            • Segfaults
          • /sbin/besbes-otta
            • Fake tool that benchmarks the time it takes to allocate a certain amount of memory
          • /sbin/getarch
            • Prints 'x86_64' or 'i686'
          • /sbin/koko-wawa
            • (Removed boost, so can't test right now)
          • /sbin/lsx
            • Symlink to /dist/sbin/
          • /sbin/sau
          • /sbin/sendstat
            • Downloads http://www.sphinux.org/56734 and does a string comparison with "SphinUS rocks other suck". The downloaded output is never used in an exec statement so command execution is not possible.
          • /bin/autodriver
            • Detects graphics card and installs proprietary drivers
          • /bin/lsx
            • Symlink to /dist/bin/
          • /bin/oba
            • Also downloads http://www.sphinux.org/56734 and does the same string comparison
            • Sends the following to http://www.sphinux.org/bug_report.php
              • date
              • lspci
              • lsusb
              • lscpu
              • lshw
              • lshal
              • lsmod
              • dmesg
              • lsblk
              • /var/log/boot.log
              • whoami
              • xwd -root ***WARNING: This takes a screenshot of the current Xorg session***
            • This script presents a fake "# Authenticating ..." text when sending the data
          • /bin/readme
            • Prints out /usr/share/horus/scripts/readme and pipes it to less
          • /bin/xhost
            • ***WARNING: Potentially dangerous: Calls "xhost +"***
            • Runs "/etc/init.d/autofs start"
          • /opt/Synaptics/HKLM_Kernel
            • Dump of Synaptics registry entries from Windows (includes some device IDs unrelated to touchpads)
          • /opt/Synaptics/HKLM_User
            • Some more Synaptics registry entries
          • /opt/Synaptics/**/*.so
            • Lots of libraries here. I have no idea what they are for
          • /usr/bin/4L-cli
            • Broken symlink
          • /usr/bin/4L-gui
            • Broken symlink
          • /usr/bin/au
            • Same as /sbin/au
          • /usr/bin/auther
            • Same as /sbin/auther
          • /usr/bin/disoff
            • Calls some ACPI methods to supposedly turn of the discrete graphics card
          • /usr/bin/dison
            • Opposite of above
          • /usr/bin/edu
            • echos a short description of readme, rkhunter, nmap, ip, nbtscan, besbes-otta
          • /usr/bin/getarch
            • Same as /sbin/getarch, except last line has "&>/dev/null 2>&1"
          • /usr/bin/mangui
            • Shows /usr/share/horus/scripts/readme with kdialog
          • /usr/bin/powercontrol
            • Performs some power management tweaks (CPU freq, VM write back timeout, SATA ALPM, etc)
          • /usr/bin/sau
            • Same as /sbin/sau
          • And yeah...I highly doubt these people could create a kernel since they can't create a distro properly:
            • Their bluetooth devices address is 9C:B7:0D:69:E7:BF
            • All of their prior DHCP leases are in /var/lib/dhcp/ and /var/lib/NetworkManager/
            • All policykit actions are automatically allowed (even on installed system): /var/lib/polkit-1/localauthority/10-vendor.d/10-live-cd.pkla

          Comment


          • #50
            Looking at base.squashfs:

            Code:
            $ cat etc/issue
            Debian GNU/Linux 7.0 \n \l
            
            $ head etc/init.d/live
            #!/bin/sh
            
            ## live-boot contains the scripts that configure a Debian Live system during
            ## the boot process (early userspace).
            ##
            ## This is the sysvinit script for live-boot.
            This is Debian Live GNU/Linux 7.0 i386 with some extra goodies, even non-free firmware blobs, and no source code.

            Inside /dist is chroot of another system, of statically built i386 binaries. /usr/Makefile identifies a Minix3 release of pkgsrc that was probably used to build it all.

            I don't notice anything malicious at first glance, but don't see anything remotely good about it either...

            Comment


            • #51
              Originally posted by johnc View Post
              Wow. Talk about ridiculous. I mean who would run Unity on ArchLinux?
              People do believe it or not. chenxiaolong does an absolute power of work providing Unity to Arch users, despite having to deal with all the Ubuntu molested packages/patches etc, so kudos to him.

              As for this "OS" in question, I'm amazed someone went to this much effort for a troll. Micheal himself must have been having a fair old chuckle even writing the article, as all the claims made by the project are somewhat easy to see through and just way too outlandish.
              Last edited by ElderSnake; 06-05-2013, 08:32 PM.

              Comment


              • #52
                Originally posted by glasen View Post
                ... from Alexandria, Egypt.
                The included (Linux) kernel, identifies root@sphinux-lsx as having built it in an EET timezone (Eastern European Time), which is used in that city.

                Comment


                • #53
                  Originally posted by chenxiaolong View Post
                  • /sbin/koko-wawa
                  • (Removed boost, so can't test right now)
                  From 'strings' output:
                  Code:
                  #           koko-wawa, is a LSX utility to benchmark your kernel's switching behaviour              #
                  # Created by Ahmed G. Elnil <yuri@sphinux.org>, SphinUX Community, Alexandria, Egypt - 2013       #
                  #                           Feel free to use, it's public domain                                    #
                  Measuring actual sleep delays when requesting
                  ...
                  And even that code seems to be stolen without credit, from Stack Overflow user Tronic:
                  http://stackoverflow.com/questions/2...ch-in-linux-os
                  Last edited by stevenc; 06-05-2013, 08:49 PM.

                  Comment


                  • #54
                    Originally posted by stevenc View Post
                    From 'strings' output:
                    Code:
                    #           koko-wawa, is a LSX utility to benchmark your kernel's switching behaviour              #
                    # Created by Ahmed G. Elnil <yuri@sphinux.org>, SphinUX Community, Alexandria, Egypt - 2013       #
                    #                           Feel free to use, it's public domain                                    #
                    Measuring actual sleep delays when requesting
                    ...
                    And even that code seems to be stolen without credit, from Stack Overflow user Tronic:
                    http://stackoverflow.com/questions/2...ch-in-linux-os
                    Thank you very much for this.

                    I've just send a complaint with many of the points discussed here to SourceForge to have the project removed. We have way more than enough proof to show that this is a shady distro not created in the interest of its users with developers that steal code and ignore software licenses.

                    Comment


                    • #55
                      Originally posted by chenxiaolong View Post
                      TL;DR: There's a script that sends logs, hardware information, and takes a screenshot of the active Xorg session to http://www.sphinux.org/bug_report.php

                      ...
                      Thank you for taking the time and exposing this.

                      Comment


                      • #56
                        Originally posted by F i L View Post
                        Thank you for taking the time and exposing this.

                        No problem.

                        Here is the exact script I'm referring to: http://paste.kde.org/759530/

                        The screenshot is being captured at line 34 and 35, the fake authentication is at line 81, and the upload process is at line 53. Another thing to note is that all of the data is uploaded though unsecured HTTP. It is incredibly easy for someone to sniff out this information using a tool like Wireshark.

                        Comment


                        • #57
                          Time to put on my best Paul Hogan voice.

                          "That's not an os; this is an os!"
                          *Pulls out Wheatonix

                          Comment


                          • #58
                            Originally posted by mark45 View Post
                            I'm pretty sure we're presented with the usual situation: the size of the OS is generally inversely proportional to its speed. When Linux was much smaller there were also astonishing benchmark results, when it matured to support a much wider array of APIs, drivers and hw it did so generally at the expense of speed.
                            I didn't hear such bullshit since a long time. BeOS, Haiku, DOS are much slower than bigger operating systems. It's because of architecture not because of being small or not. Furthermore, Linux doesn't use 90% of its features on a common PC, so your point is invalid.

                            Comment


                            • #59
                              According to this video: http://www.youtube.com/watch?v=AqupsTFyuGE ... it boots and is recognized as a 2.6.32 Linux kernel (look on the boot sequence, at 17:06 ), so it looks to me that this SphinuX is more or less a modularizing effort inside the Linux kernel that may reduce in some use-cases the IO and/or maybe some kernel modules.

                              I think that the 100% and 300% kind of speedups refer just to the use-cases when this new infrastructure reduces the IO (so in an I/O kind of benchmark it may work like 2-3 times faster) and the memory is again related with the minimalist kind of loading of the drivers.

                              As it looks, it uses standard compilers (like GCC) and similarly standard file systems (Ext3 and Ext4), so the Phoronix like benchmarking, which stresses the user-space I think it will behave (more or less) like a 2.6.32 kernel with some patches on it. Also, the source doesn't say 100% or things like this performance speedup against what. I think that is in case of Ext4 with encryption vs Ext4 with Xor++ (their encryption scheme).

                              So based on what is written, I can expect the following:
                              - some boot scenarios would boot faster on a similar package selection and using a bit less kernel memory
                              - for embedded cases, the kernel can be "up-to" 300% smaller memory
                              - in low memory systems, where it will be more IO, the smaller kernel (Sphinx) may work a bit better
                              - on disk encrypted disks, a faster encryption scheme, which may be "good enough" may be faster than Ext4 than the default Ubuntu with Encryption

                              What would not happen:
                              - Sphinux would run the same CPU bound codes (which are computed in user-space or on video card, but not on kernel) to be more than 5% faster/slower than 2.6.20+ kernels, so Michael will be able to "bust" the myth
                              - Database benchmarks or IO tests without encryption on Ext4 should work similarly as a 2.6.32 kernel
                              - Loading KDE or whatever environment with similar package selection will look and feel as any bare-metal Debian with the same package selection. SphinuX would have more bugs, but other than this, will feel very "upstreamy". Both memory wise and performance

                              But Michael is right, the specifics should be told, writing "100% speedup" or "300% less memory" without putting some strings attached is a bit misleading (to say it kindly) and it would be great if the value numbers come with a methodology about how it can be this way.

                              Comment


                              • #60
                                Originally posted by Fenrin View Post
                                the advertised RAM minimum of Puppy and AntiX is also 256 MB RAM I think. And the required minimum not higher than 128 MB.
                                I'll just put it out there that you can run Linux on 4 MB RAM and a floppy disk. That kernel will be stripped to hell, and you get basics only, but it runs and will do its work.

                                Comment

                                Working...
                                X