Slashdot Mirror
Fedora Project Considering "Stateless Linux"
Havoc Pennington writes "Red Hat developers have been working on a generic framework covering all cases of sharing a single operating system install between multiple physical or virtual computers. This covers mounting the root filesystem diskless, keeping a read-only copy of it cached on a local disk, or storing it on a live CD, among other cases. Because OS configuration state is shared rather than local, the project is called 'stateless Linux.'
The post to fedora-devel-list is here, and a PDF overview is here."
I don't see the purpose. Maybe I'm just unitiated, but wouldn't a linux terminal server work better, or perhaps some other solution. This in particular doesn't look that amazing, but I could be wrong. Does anyone out there have specific uses for this? (TFA won't load for me, so I'm going on what I see)
Those who study history are doomed to watch others repeat it.
Haven't Unix machine been doing this for years as NFS mounts? The first sun machines I used (sunos 4.1) has just a single install of the OS and two machines sharing a read only mount.
Stateless installs? Sounds a bit like the terminal server project. I smell thin clients...are they going into fashion again?
Thin clients WOULD be a blessing, I imagine. Single configuration, one update, all the "personal files" in a server somewhere -- makes for easy updating and backing up. Also keeps hardware requirements down...which [buzzword warning] "helps lower TCO and increase ROI"
Unless i've caught a large case of the stupids, it looks like we're heading back to the days of the mainframe computer which many terminals plug into. Is this good or bad or neutral? I think this is a good way to keep corporate/school/etc computer costs down while making sysadmin jobs at least a little easier.
-- Checking emails and kicking cheats `till the day I die.
On behalf of non-geeks, let me be the first to say... HUH?
I mean, I know the words. It's mostly English, and that's my first language, and I'm pretty handy with computers, but that was the most incomprehensible load of babble I've heard since the last time I watched TNG.
Can someone explain what this means, in plain English, to a regular user (i.e. non-hacker geek types)?
Wow - this is really HUGE project. I mean - it spreads from kernel, through init scritps, through X managers & enviroments to easy to use administration tools. If they suceed this could be really "Linux killer application".
And please all the "NFS root is enough" posts - read the article!
It's really disconcerting for me that practically all the distros want you to have root access even to install a simple MP3 player from their package files; and extremely distrubing that they do it by popping up KDE or Gnome windows asking for root paswords.
Isn't this what we blame microsoft for?
Disk space is cheap enough, we don't need more sharing of config stuff - we need more separation so users can use the benefits of package managers without having to get in the way of other users.
This is similar to what clusters try and do. It is important to maintain the same OS state on all nodes. Take a look at Rocks Clusters. Rocks will push the same OS image out to the nodes of the cluster. There is no reason the cluster nodes could not be workstations on a desk.
HPC for Primates. Read Cluster Monkey
Posts like:
NFS read-only & shared root is enough
+
LTSP
+
Thin clients
=> please read the article
First, what's so special about this? If you set up a network filing system for your root FS and use LinuxBIOS as your bootable image, you can have a single, central Linux install that is shared with as many computers as you like.
What would be far MORE interesting would be to have a central server with multiple images for different hardware. Then you could boot your nice, shiny IBM mainframe from the same "install" as your desktop PC or the webmaster's Apple Mac.
Another possibility is a massively parallel installer. Basically have one machine on which you are actively installing, but have that machine replicate the write-to-disk operations across the entire network to all the other PCs.
A third option would be to have a distro which set up the entire network as a cluster, but with the config files just on one machine. That way, you don't burden any one machine with having to serve the really heavy-duty stuff, such as applications.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
... to bring a company running thin clients to a grinding halt? Kill the central server... Looks interesting though.... since all config data is stored centrally, it would make sysadmin's lives much easier.
The friendliest digital photography forums on the net!
Back when mainframes were popular (the first time), they were large, expensive, and consumed lots of power... but in the long run less expensive than putting full workstations on every desk and maintaining local copies of settings, software etc. My personal feeling as to why desktops took off is because, at the time of their introduction, it seemed rediculous to have a mainframe in the home. Local copies were fine since most people only had one computer to worry about. This has changed. People now have multiple computers, or at the very least, constantly transfer info between home and work machines. Now, mainframe power is available cheeply and in a small formfactor... and with the use of broadband increasing, it is becomming more and more popular to rid the home and office of multiple full machines, and replace them with terminals that can connect to a shared environment. Personally, I would love to see this take off. It would be nifty if I could "pause" my work at one terminal, and resume it at another in another location. Also reduces overall cost for people who have, let's say, one computer for the parents and one for the kids (the latter more prone to breaking). Cheap thin-clients would be really useful here.
Mak'tal shree lok'tak mek'ta sa'tak Oz! - Daniel Jackson
Really? Their customers (you know, the people that actually pay for the stuff?) seem to like their licensing terms just fine.
The Free desktop that Just Works
From the article:
The Free desktop that Just Works
same install image will work on a lot of different hardware i.e a laptop with all the power saving features, IDE hard drives and a P4 M processor that same install image will work on a AMD desktop system with scsi drives...
thats it in a nutshell....
This must be Thursday, I never could get the hang of Thursdays.
If you read the article, you will see that:
1) they don't want users to need root for hardware (but do want users to need the admin to install certain software). This info is in the PDF. They already see that needing root for hardware install or configuration needs to be worked around.
2) the design is a hybrid or amalgamation of thin and fat client, trying to cherry pick the best of both:
applications run on local systems
software and data cached on local disk
central management and configuration of nodes
they call it a cached client technology
3) they have a plan for laptops. Stateless... instantiation, sync... things that sound vague, but they seem to have a plan because this stuff is considered in the howto. There are some notes in the how-to covering the different types of clients:
" diskless clients, which boot directly from a snapshot stored on the server
caching clients, which boot from a copy of a snapshot, cached locally on a hard drive.
Live CD clients, which boot from a copy of a snapshot burned onto a CD
thick clients, which don't use snapshots and must be maintained by another means.
"
The idea has some very cool potential for a business or network situation. I can't imagine this is ready for production, but it could be soon.
-A
First of all, I'm not associated with the project.
However, I've read what they're talking about, and here is where many people are misinterpreting:
This is not a 'thin' client in the traditional sense. The client in this case does the computations.. i.e. it actually runs the app.
In other words, the computer is not merely a display, and as such shouldn't suffer from the traditional mainframe/client shortcomings.. (you have all the CPU power you normally have)
When you think about this, think KNOPPIX and other live-cds, that is the nearest (and quite near, imho) to what they're discussing.
So... why is this different from a normal install?
A normal install has a read-write root, whereas here they're shooting for a read-only root, even if it is still on the local harddrive.
For example, if you asked me a week ago the origin of chopsticks I (like most people) would have responded China, or parts nearby.
And you'd have been correct.
Now this totally neglects the less-than-common knowledge that they were actually created in America in the 1800s by immigrants to mining communities as a means of differentiating their restaurants from more common fare
Crap. Chopsticks have been in use in China and Japan for around 5000 years. This page includes a brief history, and you can get more details here. Note that the second article points out that a museum in Shanghi actually has a pair from the Tang Dynasty (A.D. 618-907). There's also more nice information on Wikipedia.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
Bingo! If the kernel is in some remote location (i.e. Cayman Islands), then enterprises can run all their apps locally, but SCO cannot sue them for copyright violation (because the code is offshore)!
/just kidding
Sure, ping times will be a bitch, but...
davejenkins.com |
I've been thinking about this way of doing things more and more since the appearance of Knoppix, FAI, Adios, and various cluster installation facilities--and clearly, so has Redhat.
Most importantly, this
1. avoids the absurdity of moving all processing, and indeed disk to a central server
2. focusses attention on development and maintenance of prototype installations for different types of machines
Some of the implementation techniques don't seem pleasant--but they're doing things in a way that appears forward-looking.
I look forward to seeing more of this.
Matt
The project is too big, ambitious and lofty. It's just bound to collapse sooner or later IMHO. I don't think anybody /really/ wants to relearn how to deploy Linux anyway.
(Please browse at -1 to read this comment.)
Heh. I once made a stateless distro, based on Red Hat, on a hard drive. The intention was to use it as a car ogg player.
/var cannot be mounted read-only (needs /var/run, etc), so I mounted it as a 16M ramdisk, the contents of which was downloaded from /var.tgz at boot time. It worked splendid. Eventually, the slowest part of the boot process was waiting for the BIOS POST to finish.
It had / mounted read-only.
You could power down the thing whenever the hell you liked and never see fsck run.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
so here it is for those of you who don't know. From Wiki.
---
In American politics, the term astroturfing is used perjoratively to describe formal public relations projects which deliberately give the impression of spontaneous and populist reactions.
The term is a play on "grassroots" efforts, which are truly spontaneous undertakings. AstroTurf refers to the bright green artificial grass used in some indoor sports stadiums.
A "grassroots" action or campaign is one that is started spontaneously and is largely sustained by private persons, not politicians, corporations or public relations firms. A "grassroots" campaign is perceived to come from the popular feelings of some mass of people and to not be a creation of the powerful.
"Astroturfing", by contrast, is a campaign crafted by politicians or other professionals but carefully designed to appear that it is the result of popular feeling rather than manipulation. The astroturfing campaign attempts to gain legitimacy by appearing to spring forth spontaneously from "the people". If the campaign is well executed, the planners hope that the public at large will believe that "all those independent viewpoints could not have been faked."
Examples of these kinds of practices can be found throughout history, though there is a perception that use of astroturfing is increasing in reaction to the declining credibility of politicians and corporations.
Online backup with Mozy, sounds like Ozzie, but more!
A file/directory is either
- Static (not changed except by action of the system administrator), or
- Variable (subject to change at any time
and either- Shareable (multiple machines can have a common copy), or
- Unshareable (each machine needs a separate copy).
In an effort that is conceptually equivalent to the separation of the kernel tree into architecture-dependent and -independent subtrees for the Alpha port, which made subsequent architectures far easier, a lot of people have devoted their efforts to determining just how little of what goes into the file hierarchy really has to be unique to the machine.The 'aha moment' comes when you think of groups of workstations with identical hardware, which are candidates for having a common image from which they can be built, and realize that you can build a relational database that correlates MAC addresses (possibly to some other locally-unique but shorter machine number) to the HW configuration. Now, conceptually all of those cookie-cutter-identical machines are a single entity for the purposes of configuration. A lot of what FHS considers 'unsharable' is now quite 'sharable' within such a HW config group.
As workstations age, the IT department brings in a couple samples of the next HW configuration, loads drivers, tests against the app suite, and when they're ready for primetime, the vendor delivers them, the MAC addresses are added to the database, the workstations boot up, find Mommy (bootp server), and Just Work. The user can log out of an old computer and into a new one, and find all his 'stuff' right where he left it. It's the only sane way to compute in an institutional environment.
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
This sounds like a great step forward for laptops as well as desktops that are to be "locked down".
I think there should be a more general concept of overlayed filesystems, where a FS could be mounted on top of another FS "with transparency", so that you can see all the files in the entire "stack". A standard "ls" would show 1 instance of each file, with the "highest level" FS taking precedence. A modified program might be able to see all the versions of a particular file and be able to copy one to another (if permissions allow).
If each FS could be mounted RO or RW, then you could have a local copy of everything on a CD or DVD, but make it appear writable by mounting another FS on top (either a local HD, USB pen drive, NFS mountpoint, etc). Recovering back to the original install would be just wiping out the modified files, so the underlying files are now visible.
This would be good for:
- fully functional Linux systems based of a CD or DVD
- FS snapshots for backup or testing
- intrusion detection (diff across file versions)
- version control of the entire OS image
Now, if only I were smart enough to actually write the code.
Separate the state from the behavior with respective hardware, sounds interesting. Definitely they will need to break all the encapsulation layers built in todays modern OS and identify the patterns that represent common behavior and common state.
In the article, it makes me wonder, is it better to centralize state or behavior? For instance, centralizing state would be more efficient, but if state was local, you truly own your data (just unplug the network connection). Also, doing the reverse, well, that's pretty much near a basic terminal.
To me, it sounds like java webstart or rio without the fat OS lying underneat it (which is good).
Only if you have had your head stuck in the ground. Freebsd has had this for ages.
This is a very interesting project. As I understand the article, the point - long term - of the development effort is to try to get Linux (RedHat) adopted on the desktop by appealing to the TCO mentality of the IT department rather than by appealing to the desire of the end user to actually get stuff done. In other words, if the savings to IT of administering your machine centrally outweighs the benefits of you (corporate cube dweller) being able to configure your machine to your liking and use it as you see fit, then IT wins, and Linux makes an appearance on the Fortune 2000 desktop.
'Thin client' was the first attempt to dethrone MS in this way, but this approach appears much more sophisticated, and consequently much more likely to succeed. Without seeing how the whole thing plays out I really have no idea whether the approach is successful or not. But it's a really nifty shot across the MS bows.
Whether this goes anywhere or not ends up being decided by (as with most IT projects) whether the services provided by IT to the end users are adequate (in which case IT gets their way) or so obnoxiously limited that the end user cabal ends up storming the IT department with burning torches.
Shared state is practically equivalent to stateless? Since when?
Very simple, it is stateless so it remembers nothing from command to command. Here's what it would look like to use it:
I for one plan to skip this distro.The bug was closed as WONTFIX because the reporter was an obnoxious prick. Referring to the developer as a Moron on repeated occasions. The fact is that if you want people to help you, yelling abuse is not a particularly good strategy.
Cheers Koz
Hi... We run a project called DRBL (Diskless Remote Boot in Linux) . The website isF %A5%CE% AA%CC%A4%C0%A7G/DRBL%A8%CF%A5%CE%AA%CC%A4%C0%A7G_2 0040820.pdf
a .php (Traditional Chinese)
http://drbl.nchc.org.tw (Traditional Chinese)
and
http://drbl.sf.net (English).
Maybe someone can have a look at that, some part of DRBL are similar to this Stateless Linux project.
DRBL runs well on RedHat, Fedora, Mandrake and Debian.
In Taiwan, more than 100 sites already downloaded and run DRBL, some of them are schools (Primary/High school/University), some of them are NPO and buisness companies.
check this:
http://drbl.nchc.org.tw/sites/98_DRBL%A8%C
Also, there is a program comes with DRBL called "Clonezilla". It can let people to massively clone the system image to the harddisk of client computers. The function of clonezilla is quite similar to the Symantec Ghost Corporate Edition®. For more information about clonezilla, check this:
http://clonezilla.sf.net (English)
and
http://drbl.nchc.org.tw/clonezill
Although I've never used it, a Domain of OsX machines can mount and boot from remotely networked disk images. Also, a standalone machine (like a laptop) participating to an Apple directory will authenticate against the server providing "terminals" for domain users not present on the machine's local credential database. Domain accounts can be coupled to local accounts available when unplugged from the domain. Save for the first item I've experienced the setup and found it very simple to configure & use. The only kludge is the use of traditional UNIX perms (ugo) that doesn't quite fit the picture. Tiger should take care of that next year. I hope RH etc will make their system "drop in" compatible with the Apple solution (basically it's openldap); the only problem is that consumer i386 HW only has chesy BIOS rather than openfirmware which I think is used to simplyfy the remote booting configuration process.
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
We've been running linux clusters like this for years and have recently released the software for doing it. The software is called oneSIS (http://onesis.sourceforge.net/). This does mostly everything it looks like the fedora stateless project aims at doing:
- Read-only root NFS
- bit-for-bit identical root filesystem
- local disk cache (if desired)
- fine-grained control of independent node/role behavior
- mkinitrd (only better, IMHO)
However, it supports more than Fedora. Currently supported are redhat,fedora,suse,gentoo,and debian.
I've kept it pretty quiet so far, but I guess now might be the time to go public.
I am currently running 200 workstations in a thin client environment and we really could not be happier. Not to mention that those 200 are running of a single redhat cluster with nearly 100% uptime for the year. What possible benifit am I going to get over my current environment? Our clients are a mixture of junk we got from a recycler, cdboot from a hacked slax distro or flashboot mini-itx boxes. Total maintenance time per month is measured in mere minutes. And no I am not running LTSP, to complex and I can just buy neoware boxes already configured as a redhat x terminal.
Got Code?