The small Linux distributions are an interesting alternate universe. Very hobbyist in some respects, as often it's mostly repackaging standard distro stuff, getting older software to compile, writing simple GUI scripts -- not exactly developing a semi-embedded Linux subset with state of the art tools. Very hackish. And I mean that in a good way…
If you do the Linux From Scratch book and follow the embedded track, you should wind up with a busybox based distro around 33MB's on disk, plus you will learn a LOT about how a distro does what it does. I highly recommend it.
I can't speak for DSLR, but I can say why Puppy Linux runs as root without disaster. (Spent a couple of years writing utilities for them.)
Basically you design the system so that root has no special powers. Imagine if all of your storage was write-once, like a CD-R. What damage could root do? Almost none. Maybe there is a union file system for /usr and /home. Disregard all changes to /usr, when you reboot a fresh /usr is extracted from disk. Stuff like /home is incrementally saved. You can re-wind to any point in history. That is how Puppy (in CD-R mode) works.
About the only real threat that root poses is accidentally dd-ing over the OS boot partition. With some kernel patching you could simply hide the /dev node after the boot is done with it. Though that makes updating harder. Any threat can be neutralized, but the whole OS gets slightly more byzantine as a downside.
The root/user distinction places all your faith in octal permission bits. In some ways a properly designed run-as-root system is less risky, because the safeties are baked into the OS at a much deeper level. It is the difference between a dangerous machine having physical safety interlocks and paper-thin "for your safety" policies.
> With some kernel patching you could simply hide the /dev node after the boot is done with it.
At some point we have to make the call on diminishing returns. It will always be possible for root to bork a system (without a rewrite of many, many utilities that rely on root permissiveness), it's just a matter of how hard we can make it to do that accidentally. To be clear, I think this work is very useful and appreciated though. As someone that spends almost all of every working day in terminals on remote systems, often as root, I applaud any effort to reduce catastrophic mistakes. Every time I have to rm -rf as root there's that little after-I-hit-enter-panic, where I have to assure myself I double checked and didn't accidentally just delete /bin. The root is protected from the errant rm mistake, but there's oh so many more ways to reduce a perfectly fine system to an unbooting heap of hardware.
> The root/user distinction places all your faith in octal permission bits. In some ways a properly designed run-as-root system is less risky, because the safeties are baked into the OS at a much deeper level. It is the difference between a dangerous machine having physical safety interlocks and paper-thin "for your safety" policies.
> > DSLR's approach to security is different . It is possible to run as root without causing a global disaster.
> Is there any more information available on how this is achieved?
+1 to this remark, currently unanswered. Is the "NEVER RUN AS ROOT!" mantra from modern Linux practices, or has it been that way since the mid-90s? After nearly four years of using Fedoras, I'm getting better about remembering what operations require root privileges, but I'll still grumble every time I have to enter the root password to do something as trivial as mounting a flash drive on someone else's computer. (I can't remember, offhand, where that setting is/what it's called that lets normal users mount drives)
Almost 20 years ago I typed "rm /lib" instead of "rm lib" by mistake. Kernel panic messages started to flash on the terminal and I felt butterflies on my stomach. It was a huge (at the time) Sun machine, took more than 12h to restore it.
The other late evening, I typed "sudo pip uninstall pip" instead of "sudo pip uninstall pil" Not that bad, but i was on an outdated distro (13.04) and I couldn't apt-get pip back. :< It was time to move to 13.10 anyway.
Is the "NEVER RUN AS ROOT!" mantra from modern Linux practices, or has it been that way since the mid-90s?
I think that goes back all the way to Unix and its multiuser environment, where one admin's mistakes could affect everyone on the system - so people were naturally scared of root.
On the other hand, on the earliest personal computer OSs, which were basically single-user (many don't even have the concept of a "user account"), that only user has full control like root but that wasn't really perceived with as much apprehension since the only thing a mistake affects is the sole user.
With DSLR and all the other tiny Linux distros, I sense that the intention is these are to be used by a single user.
Ah... That is very insightful, thank you. I continually forget the days of timesharing, etc. For my entire life (born during the Tiannamen Square riots), personal computers have typically hosted one user at a time.
That statment is actually true for the entire existence of personal computers... you might even say it's the definition of a PC. However, Unix didn't start on PCs, it started on minicomputers.
While the floppy is justifiably dead, it is a little strange to see basic installs taking up so much space these days. Thankfully the core-os type projects (os for densly populated vm servers) are helping a bit -- even if deduplication/running root from /nfs etc -- is probably a more expedient (and permanent) way to reduce footprint per vm (1 Gig divided by 1024 vms is just 1Mb per vm after all...).
uLinux or picoLinux (I don't remember very well the name) -> Runs on one or two 3.5 floppies. There is a version with 3 or 4 floppies with an X-Windows included.
It was one of my first distro and it was awesome. A base system than ran in one floppy and then you could optionally add and combine more floppys depending of what you wanted (X system, IDE, games, latex, etc...)
It was kind of the ancestor to Live CD
Probably because most users would prefer that the sites they visit actually work.
Supporting other embedded languages might be nice, but of course, unless all the major browsers also support the same, sites would have to provide an alternative in javascript for everybody else.
Not supporting javascript at all when it's integrated so deeply into the web, when you will doubtless be able to simply turn it off if you want, seems unreasonable.
For better or worse, the web is becoming a platform for distributing javascript binaries which execute in the browser. Unlike most other platforms, however, at least you can turn it off or view the source or block parts of it if you like.
Every site should be able to function normally without JS. Granted that doesn't necessarily hold true for web apps, but for regular sites they shouldn't lose functionality because somebody has JS disabled (or doesn't have it at all!)
I agree with you. I have js disabled by default and every time I run up against a site that uses client-side templating I find it incredibly annoying - I understand the rationale behind it but it's still annoying how many things tend to break without javascript.
However, you can't design a browser around an expectation of what the web should be like.
And anyway, it could be worse. If there were no javascript we would all be complaining about the dominance of VBScript in the browser.
I really hope that people start installing and testing against minimal browsers.
Modern browsers are fucking huge. Obviously they do very much more than browsers used to, but most of the time I really am just reading text and I don't want a bad designer's idea of novel UI to get in the way.
Sadly it seems like hundreds of years of design iteration for the printed word are being weakened.
Too bad nearly every page is broken on it (CSS wise). The only error it detected on my site was that newfangled <doctype html> declaration... The entire layout was jumbled.
If you're a developer who doesn't know very well how Linux distributions (or operating systems in general) work, you should spend a weekend or two playing around with an embedded Linux distro like this. Unfortunately DSLR's build environment does not seem like the easiest to understand for first-timers.
For example, instead of Makefiles per package, there's a package-specific shell script which incorporates some magic from scripts/build_package and is then sourced by the same to add some functions, with references to patches in a separate directory, and build dependencies tracked by a Makefile.deps file that's included by the root Makefile before the build_package script is run, which incidentally has tons of package-specific logic built in. You'd be re-reading 10 files over and over any time you build or troubleshoot a package.
All of this inside of a chroot using a bootstrapped cross compiler, which lord knows most people have never dealt with before. And the dependencies for building the cross-compiler aren't built from source, meaning this isn't a fully bootstrapped build environment, to say nothing of tracking versions. The resulting packages will vary from system to system, and it will be more difficult to port to non-x86.
Yocto seems to be an attempt to make a standards body for embedded Linux development. It's neat and probably a huge boon for corporate-sponsored development, but overkill for the casual developer to learn more about Linux. All you need is a HOWTO to step you through building a toolchain and setting up the files needed to boot up with some programs running at start time, which LFS provides.
Linux From Scratch [1] is the de-facto standard in building a Linux system from the ground up, with more detail in CLFS [2]. You can look at Buildroot [3] as a model for embedded systems. SLAX [4] is a bootable embedded distro with tons of friendly documentation, and is a derivative of Slackware that also uses buildroot/busybox.
When I was in high school I had a 16mb flash drive, so I made a tiny Linux distro for it! It had X11 with blackbox, a web browser (dillo), a mail client (sylpheed), an IM client (ayttm), a VNC client, a music player (xmms), a terminal (rxvt), busybox with a lot of options set, and ssh (dropbear).
I just found the image of that flash drive, if anyone is interested. Keep in mind it is unchanged from its original form in 2006 :)
Back in 2008 when I was in high school I picked up computers that were thrown out by the school with 256 or less RAM. The smallest one only had 64mb of RAM! I managed to install Ubuntu 6 on it but I could feel the lag. I found DSL and I had no trouble running it on them at all. The iSO was only 50MB irrc. It was damn small.
I keep a copy of SuSE Linux from 1998. It have six CD-roms (in a time were Internet by dial-up was not cheap here), but I remember that I managed to install it on 200-300 MiB with a machine with less of 256 MiB of ram, and It could run GNOME 1.0 over KDE !!!! And it was running pretty soft.
This remains me about my own LFS/busybox based stuff http://freecode.com/projects/minili
"minili - miniMAL liNUX 3.8 MB size. You can download and burn it to CD/DVD or Try with virtual machines.If everything is fine,all you can do is,
to login to this linux and run few basic commands."
It was maybe about 5 years ago that I was still running DSL on a old Dell Pentium II laptop on the side of my desk. It made a decent ssh / x3270 terminal and acted as a digital photo frame most of the day. But it could do some light web browsing and stuff in a pinch. Booted from a mini CDR and used a 32 meg USB thumbdrive as storage.
My first linux that I managed to run on a vm. I only had access to dial up internet and thus could only download a very small package. The screenshots make me very nostalgic indeed.
I somehow doubt it. Sure, there's a lot less stuff running, so there are fewer wakeups. But on the other hand, it's missing some essential power-saving software like `acpid` that tells bits of hardware to take a rest in the first place.
acpid being only one of the tools usually there to interface with power management, I'm not really up-to-date what Ubuntu uses nowadays. And yes, as with a lot of hardware stuff you're going to end up in the kernel in the end, but without any management/supervision software (never mind drivers), you usually won't get a quiet and cool laptop. Try starting a barebones arch installation on one these days, without acpid, tlp etc.…
So just for starters... For those who downvoted my comment take a look: Dillo 0.8.6 (1) ; sylpheed (2) ; dhcpcd (3). According to the sources http://dslr.dimakrasner.com/i686
In Linux/FOSS distros using outdated software is really not good idea unless you know what you are doing or have support from the distro which have people that should be able to fix the security vulnerabilities. e.g. RedHat, Suse, Canonical, Debian.
Using software which is dead upstream often makes distro maintainers want to remove the software from the repository because they are not able/want to maintain. BTW... I'm curious about which version of GTK+1.x is he using. GNOME does not support GTK+-1.x for years how wonder who fixes the security vulnerabilities also.
To quote the DSLR's author Very often, new versions of applications are heavier than older ones (Wirth's Law). If the old version already solves the problem ... without any compromise in security or stability, why make the switch [to a bloated new version]?
The author SAYS that, but that's ALL he says. There's nothing to back up the claim that the older versions are not a compromise in security. Are all known vulnerabilities patched? Are security fixes backported?
Almost never:
which may causes issues likes thoses! :
From Wikipedia & OpenBSD: The affected versions of OpenSSL are OpenSSL 1.0.1 through 1.0.1f (inclusive). Later versions (1.0.1g and ulterior ) and previous versions (1.0.0 branch and older) are not vulnerable. Installations of the affected versions are vulnerable unless OpenSSL was compiled with -DOPENSSL_NO_HEARTBEATS.
