Does Linux "Fail To Think Across Layers?"
John Siracusa writes a brief article at Ars Technica pointing out an exchange between Andrew Morton, a lead developer of the Linux kernel, and a ZFS developer. Morton accused ZFS of being a "rampant layering violation." Siracusa states that this attitude of refusing to think holistically ("across layers") is responsible for all of the current failings of Linux — desktop adoption, user-friendliness, consumer software, and gaming. ZFS is effective because it crosses the lines set by conventional wisdom. Siracusa ultimately believes that the ability to achieve such a break is more likely to emerge within an authoritative, top-down organization than from a grass-roots, fractious community such as Linux.
There is some merit to what Siracusa is saying, at least on gaming and multimedia fronts.
Windows was a hamstrung peformer for graphics until NT 4.0 saw rearchitecture which placed key portions of the OS (including 3rd-party graphics drivers) at a much lower level.
This is like comparing a monarchy with anarchy, without acknowledging that there are in-between solutions that have advantages of their own. Democracy (and representative democracy) being one example.
Not saying the linux development community should be a democracy with everything voted on or whatnot, just saying that there may be creative approaches that have yet to be explored. You'd think smart people with a penchant for game theory would be working on it.
Food for thought.
Personally, I think the Linux kernel manages these issues quite well, if (by conventional standards) rather inefficiently.
The practice, as I see it is: "The current rules (layering, etc.) are enforced rigourously (at least in Linus' tree) but radical rewrites
of the rules take place relatively often"
So if ZFS really does achieve wonderful things by violating the current layering it WON'T be accepted for Linux's kernel, but, if Linus can be convinced (via an appropriate chain of lieutenants, usually) that the layering is really an obstacle to achieving these things, we might see a completely new layering appear in 2.6.25 or somewhere, into which ZFS can fit. The inefficiency
comes from the number of substantial pieces of work that get dropped because they don't fit in, or were misconceived. A more economically rational system would try to kill them sooner. Also, inefficiency arises from the fact that changing the filesystem layering would require every existing filesystem to be rewritten. Linux is notoriously unfazed by this, but in a commercial world, I suspect this would be too hard to swallow and you'd end up with all your filesystems fitting into the model except one, from whence come bugs and code cruft.
Linux will "support gaming" once games are supported for Linux. Linux has OpenGL, OpenAL, all the illusionary walls are market-made. Linux is a platform to build on without the fear of being obsolete in 2 years. DOS games nowadays run on DosBox, as do early Windows games. Even XP needs tweaks to run Win9X games. How is targeting a moving sucky platform preferable to one that is open? Easy. Games sell for 6 months tops. You get the initial sales, you get the money. After that it's tough shit if it won't work after next Windows Update(tm). I have used Linux since 1994, but work in the IT industry. I am constantly amazed by the amount of BULLSHIT the windows folks put up with. For weird quirks "shit happens" is the most common reply.
'Once scientists, even the dim-witted social scientists, get muzzled, the Western Civilization is finished.' - oldhack
Linux and other open source projects are getting a harsh lesson in what it is like to ship consumer grade software products. No more RTFM! No more 'did you submit a bug report???' No more this bug/problem is not our fault since we don't control such and such library we use.
Project vs Product
Everyone is impressed with how far you've progressed when you are working on a project.
Everyone is pissed off with how much you've left undone when you are working on a product.
Welcome to reality open source developers. Before long you will all be saying "Damn, if I have to work this hard to make a consumer grade software product I might as well be getting paid to do so"
http://en.wikipedia.org/wiki/ZFS
With Democracies, you end up with the tyranny of the majority, regardless of whether the minority opinion is the correct one. Under a Republic form, a large enough minority can plug up the works and force negotiation with the majority before a final solution is agreed upon.
The Linux Development community needs representative decision making, there are too many voters, hence, almost no direction or real progress towards a cohesive goal. Nothing will change without true leadership, and sadly, accountability.
You cant measure progress without accountability for failure. Socialism has not worked in ANY form, and it wont work for Linux either.
Alternativ approaches to implementing subsystems of the Linux kernel are often developed concurrently, in parallel, and there's a system you can compare to darwinistic evolution that decides (in most cases) which one of a given set of workalikes makes it into the mainline tree in the end. That's why the Linux kernel itself incorporates, or tries to adhere to, a UNIX-like philosophy - make a large system consist of small interchangeable parts that work well together and do one task as close to perfect as possible.
That's why there are so many generic solutions to crucial things - like "md", a subsystem providing RAID-levels for any given blockdevice, or lvm, providing volume management for any given blockdevice. Once those parts are in place, you can easily mingle their functions together - md works very nice on top of lvm, and even so vice versa, since all block devices you "treat" with one of lvm's or md's functions/features, again, result in a block device. You can format one of these blockdevices with a filesystem of choice (even ZFS would be perfectly possible, I suppose), and then incorporate this filesystem by mounting to whereever you happen to feel like it.
There are other concepts deep down in there in the kernel's inner workings that closely resemble this pattern of adaptability, like, for example, the vfs-layer, which defines a set of reuqirements every file-system has to adhere and comply to. This ensures a minimal set of viable functionality for any given filesystem, makes sure those crucial parts of the code are well-tested and optimized (since everyone _has_ to use them), and also makes it easier to implement new ideas (or filesystems, in this sepcific case).
Now, zfs provides at least two of those already existing and very well working facilites, namely md and lvm, completely on its own. That's what's called "code-duplication" (or rather "feature-duplication" - I suppose that's more appropriate here), and it's generally known as a bad thing.
I do notice that zfs happens to be very well-engineered, but this somewhat monolithic architecture still bears the probability of failure: suppose there's a crucial flaw found somewhere deep down in this complex system zfs inevitably is - chances are you've got to overhaul all of its interconnecting parts massivley.
Suppose there's a filesystem developed in the future that's even better than zfs, or at least better suited to given tasks or workloads - wouldn't it be a shame if it had to implement mirroring, striping and volume-management again on its own?
Take an approach like md and lvm, and that's not even worth wasting a single thought on. The systems are already there, and they're working fantastically (I'm an avid user of md and lvm for years by now, and I frankly cannot imagine anything doing these jobs noticeably better). I'd say that this system of interchangeable functional equivalents, and the philosophy of "one tool doing one job" is absolutely ideal for a distributed development model like Linux'.
It seems to be working since the early nineties. There must be something right about it, I suppose.
:%s/Open Source/Free Software/g
YTARY!
It's not just Andrew Morton, it's basically every core linux kernel hacker that has spoken on the issue.
It's pretty obvious; I don't think that even the ZFS developers will deny it. They'll just say "it's a layering that was worth breaking".
It has some really nice features that are either not in Linux filesystems or not well implemented in Linux filesystems. It's supported by Solaris, FreeBSD, OSX, and possibly some other operating systems, so it'd be handy if it also worked natively in Linux. It could be like FAT32 for people who need to share data between OSes and don't need Windows. Except unlike FAT, ZFS is actually well designed and has "modern" features.
Reiser4 introduced us to all sorts of interesting capabilities never before seen in a file system (at the time) but I believe this same "layering violation" attitude pretty much put a stop to any of it getting into the kernel. The Reiser guys were forced to pretty much cripple their file system feature wise if they were to have any hope of getting it included in the kernel.
See Reiser4 Pseudo Files as one example.
I can understand that in certain cases "layering violations" are bad, but Linux kernel developers don't even seem to be willing to experiment or think outside the box at all.
Both sides have valid arguments... I don't think there is any easy solution, but it would be nice to see more forward thinking in the community.
Open Source Time and Attendance, Job Costing a
ZFS is a file system developed by Sun over the past several years. But the important thing is, in this context, that the ZFS design philosophy (never mind the actual design, which isn't what this discussion is about) differs from that of ordinary file system design. Most file systems make strong assumptions about reliability of the underlying block storage facility: there's some gizmo down there, whether it be a disk (for itsy-bitsy systems), a RAID set (for not so bitsy systems), or a SAN, that reliably stores and retrieves blocks with reasonable performance. ZFS doesn't do this. It manages many details of the storage layers -- it does RAID its own way (to get around problems that conventional RAID doesn't solve), and does volume management itself as well.
From the point of view of a UNIX/Linux file system person, this seems very weird. However, these ideas are not really new or revolutionary (there are new things in ZFS, but this philosophy isn't one of them). It pretty much describes how network storage vendors (NetApp, EMC, etc) have been building things all along.
Am I part of the core demographic for Swedish Fish?
. How is targeting a moving sucky platform preferable to one that is open?
The moving sucky one has ninety plus percent of the home desktop market. Linux has less than one percent, and I've never seen any credible figures suggesting otherwise. Why target a tiny niche market when you can target a huge one?
And bear in mind, the proportion of linux users who are serious about gaming and do not have access to a windows machine is probably one percent of Linux users. So even if you target windows, ninety nine percent of Linux gamers can play your games anyway.
"I realise this is not a very popular opinion but it's the truth, and there for needs to be said" -Bill Hicks
I think you need to read the article you linked to, because ZFS is very very different from ReiserFS and ext3.
Layers are both easier to code, to understand, and to test. Layers/boundaries between software are your friend. To some degree that is why the Internet, based upon a layered network model (TCP on top of IP on top of Ethernet) is so diverse.
Layering is what keeps things manageable. One you start getting your software tentacles into several layers you make a mess of things for both yourself and others. Its a tradeoff--complexity/speed vs simplicity/maintainability/interoperability.
Open source software gets better because new people want new features to which they contribute. You can't blame Andrew Morton for disliking what ZFS is going to do, this is just how people work. This is why they say you can't teach an old dog new tricks.
That said ZFS is one of the coolest things to happen to your files in a long time. The current disk block device usage is basically the same from the beginning of computing, it is ancient and actually quite stupid. Over decades layers keep getting added to it to make it more robust, but really it's a monstrosity. Partitions are dumb, LVM is dumb, disk block RAID is dumb, monolithic filesystems are dumb. All the current linux filesystems should be thrown out.
I don't want to care how big my partitions are, what level parity protection my disks have, or any of that junk. I want to add or remove storage hardware whenever I want, and I want my files bit-exact, and I want to choose at will for each file what the speed vs protection from hardware failure is. Why shouldn't one file be mirrored, the next be stripped, and the next have parity or double parity protection? Why can't very, very important files have two or three mirrors?
From the current status of ZFS however I think this could be quickly built using GPL 2+ by one or two determined people, and it would involve gutting the linux file systems.
"I don't know that atheists should be considered citizens, nor should they be considered patriots." George HW Bush
you can't even run FC3 binaries on FC4
You can run RHEL3 binaries in RHEL4 however. And you can happily run Linux 1.0 binaries on the latest linux development snapshot. Thats because Linux DOES have a stable ABI: The syscall interface. That's the REAL ABI the Linux kernel has to support, and it's the one that it's really guaranteed to be stable. What you think as an abi it's not an "abi", it's an INTERNAL ABI. Drivers are not "software built in top of the kernel", they're plugins. And Linux developers do not care about it because linux is open source, in the open source world you can change source easily and it gets usually merged into the kernel. Basically, the Linux kernel gets more benefit from a internal unstable ABI that gets changed when it's needed and that improves all the linux drivers, than getting a stable internal ABI that only benefits a couple of external OSS drivers and another couple of propietary, illegal drivers.
Linux has no direction, no goals
That's what happens when you give everybody freedom to modify your code; everybody extends Linux in unexpected directions, that happen to be the directions the people (profesional world) desires because it's the people (profesional world) who actually develops the features. For example, some people have made Linux scale in machines with way more CPUS of what your beloved Solaris has ever run, and now other people are adding hard realtime support to the core Linux kernel, which happens to make Linux beat latency records on Wall Street servers. It all was unexpected; IT however seems to like it.
I have spent the last three days teaching someone how to use windows XP when all they used to use was windows 98. Every interface is different. Stop teaching interfaces and start teaching ideas. Stop teaching MSFT word, start teaching word processing. Teach spreadsheets not excel.
I can sit down in front of any computer and begin to figure it out. i wasn't taught windows, I learned about windows from windows. I learned about OS X from OS X. and I figured out how to make a custom kde setup from KDE.
You want to know what I find short comings in them all. They are tied to one group, one development process. I want an OS that has the ease of use of OS X, with the multi-platform binaries of java, and the remote windowing of X. I want to carry my home directory files on an encrypted thumb drive, and load up my files, whether or not the OS is OS X, linux, windows, solaris, plan 9, or what ever else the future may bring.
we have the knowledge and technology to do that today.
i thought once I was found, but it was only a dream.
Layers might not be ideal, but they're consistent. The filesystem does its part, RAID/LVM does its own, etc.
ZFS seems to want to take all over the disk subsystem. Why? Is there a reason why it needs its own snapshot capabilities, instead of just using LVM?
These sorts of things always smell fishy to me, due to a feeling that once you start using it, it locks you in more and more until you're doing it all in this new wonderful way that's incompatible with everything else. Even though it's open source, it's still inconvenient.
This approach reminds me a lot of DJB's software: If you try to get djbdns you'll be also strongly suggested to use daemontools as well. The resulting system is rather unlike anything else, and a reason why many people avoid DJB's software.
Lovely biting sarcasm aside, to be honest, our storage layering in Linux leaves much to be desired. As witness the slow pace of improvement of the volume manager in recent years. This does not prove that layering is bad, but it suggests that our current conception of layering sucks pretty badly. For example, we are burdened with a ridiculously complex interface between application programs and kernel-level volume management support. Managed volumes live off in their own name space. Why can't I say "/dev/hda, you are now snapshotted, shazam"?. No, instead I have change my system over to use /dev/mapper/snapshotted-hda or some such nonsense. Similarly, we are unable to manage all block devices using the same administration interface. No higher level raid integrated with the volume manager, instead this is a separate subsystem that fights a lot with LVM. Partition support hopelessly misfactored and broken. It goes on and on. Nothing unfixable but lots of unfixed brokenness. Compared to this mess, Sun's massive layering violations seem like a breath of fresh air.
But the thing to do is fix our broken implementation of layering and not be fooled into thinking that layers are bad. What is bad is exactly as the author here claims: it is bad to have no powerful capability to cross layer boundaries so that applications see a simple, powerful model instead of the current situation, where one's face is constantly rubbed in the minutae of layering administrivia. ZFS actually has layering, it just bypasses some traditional Unix subsystems and takes care of the functionality itself. But is wrong to conclude that this must therefore be the optimal approach just because it improves on the mess that preceded it. If ZFS internal interfaces are worth using, then they are worth using as core interfaces, not ZFS-only interfaces. Translated into Linux terms, the implication is that it is high time to get busy and rectify some of the serious deficiencies in our storage model. Not by mashing all the layers together, but by teaching them how to get along more efficiently and powerfully, and not be so layered that important things don't even work.
Note: perhaps the biggest design distinction between Linux and other Unixen is that, internally Linux is all just one big flat function space where anything can call anything else and share any data. This is said to be a reason why Linux is more efficient than, say, the Mach kernel with its microkernel layering. If being all one big hairball of functions is good for memory management, vfs, scheduling and so on, then why is it not also good for volume management? I don't know the answer to this, but I do know that we have plenty of bogus layering in our storage stack that has really slowed progress in recent years and needs a good dunging out. Any nonbogus layering can stay.
Have you got your LWN subscription yet?
"Ease of use. Nobody has sat first time users in front of a linux desktop and watch them puzzle over what those multiple desktops do, or how to switch between them.......If there is one thing I would suggest, get Ubuntu played with by ordinary grandma's so you can see how they get confused."
Just because your grandma is a little slow (okay, ALOT SLOW) does not mean all of them are.
My grandmother WAS sat in front of an Ubuntu box for the first time, and after 5 minutes, she asked me why her windows PC did not have Desktop switching, as it only makes sense, rather than constantly minimizing countless windows. Since she already has Firefox on her PC, there was no great hunt for the Big Blue "E" aka "the internet", and after a short explanation about how she, as a user, has her own little piece of the computer called a HOME FOLDER, and can save all her stuff there, she was set.
I am so tired of this myth that only people with a Mensa I.Q. are capable of understanding how to use a non-windows based system. Granted, she wont be editing config files or writing code, but how many outside the IT industry do that on a regular basis?
Mod me insightful (or fraking obvious, take your pick)
But the OSI layers are guidelines that help design things, not rigid levels that must be maintained. They are mixed up ALL the time. As a simple example, see Layer-3 switches. These are devices that simultaneously work at Layer 2 and 3 when it comes to dealing with traffic. They break down the traditional view of a separate router and switch, and they are good at what they do. There's plenty of stuff at the high end that's similar. Many things that are part of the presentation layer are actually done by the application (like encryption in SSH) and so on.
There's nothing wrong with having a layered design philosophy as it can help people decide what their product needs to do, and what it needs to talk to. For example if I am designing an application that works over TCP/IP, I really don't need to worry about anything under layer 4 or 5. However it shouldn't be this rigid thing that each layer must remain separate, and anything that combines them is bad. I don't need to, and shouldn't, take the idea that my app can't do anything that would technically be Layer 6 itself. Likewise in other situations I might find that TCP just doesn't work and I need to use UDP instead, but still have a session which I handle in my own code (games often do this).
Had we stuck to the OSI model as a maximum, rather than a guiding principle, with the Internet, it probably wouldn't have scaled to the point we have now.
"I mean, although ZFS is a rampant layering violation and we can do a lot of
the things in there (without doing it all in the fs!) I don't think we can
do all of it." http://lkml.org/lkml/2006/6/9/409
It sounds like his main point was pointing out problems with the current file system, rather than saying ZFS is bad. I bet he simply thinks they should try to implement a much better file system than ext3 without breaking the current layering scheme. I don't see why this is so bad. Why not try it, and if it fails miserably, ZFS is already here.
I think the author of the article took everything out of context and was just looking for some ammo against Linux. His blog post sucked. He just says the same crap that everyone always says. I'm not saying there are no problems, but I don't see how any of the problems relate to Andrew Morton saying the Linux file systems need to be upgraded/replaced.
The real reason Linux isn't popular has more to do with marketing that technical issues. People have always pointed to one feature or another where Linux is weak and say that it won't be viable until the feature is there. The simple fact is that Linux is now ready for the desktop technically. It is the marketing which Linux and more generally open source needs to perfect.
To address the parent:
1. Fonts are not something I even notice a difference in. I can't imagine anyone making a decision on this basis.
2. Linux is now just as easy to use as Windows for the average user. Many devices will be supported without installation of special drivers, and in many respects this experience is easier than windows. For example, my GPS device plugs straight in and works. To use it under Windows I have to keep installing a driver. Not just once but every time I use it. I don't know why. I don't know how to fix it on Windows.
3. Graphics issues - Desktops like Suse and Ubuntu are well integrated with consistent styles. While there is a broader range of layouts than with Windows, this is not a barrier to adoption.
4. Lack or help. I don't know of any software which has effective help; be that Windows or Linux. Linux has man pages of course, but thats too technical. I agree that documentation could be better, but popular applications are generally easy to use without detailed help. The lack of local help is not a big factor, and is mitigated by good online resources such as FAQ's and mailing lists.
5. This last one is odd. You want a "bundle of software that fits my needs". Linux may have been inspired by a philosophy, but there is no suggestion that users must share it. The fact is that under Linux you have access to a huge number of applications out of the box. Under Windows you will need to purchase software piece at a time. I would rather just be able to download a program automatically.
None of these reasons are real reason why Linux is not popular on the desktop. One real reason is gaming support - one of the primary reasons many of my associates say they still have Windows partitions. If only I could play CS on Linux....
You're right, that's why nobody is using Linux for real systems.</sarcasm>
The problem with a "traditional" layered model is that the file system has to assume that the underlying storage device is a single consistent unit of storage, where a single write either succeeds, or it fails (in which case the data you wrote may or may not have been written). This all sounds very good and file systems like ext2 are written based on this assumtion.
However, if the underlying storage system is RAID5, and there is a power loss during the write, the entire stripe can become corrupt (read the Wikipedia article on the subject for more information). The file system can't solve this problem because it has no knowledge about the underlying storage stucture.
ZFS solves this problem in two ways, both of which reuires the storage model to be part of the filesystem:
- Each physical write never overwrites "live" data on the disk. It writes the stripe to a new location, and once it's been completely committed to disk the old data is marked as free.
- ZFS uses variable stripe width, so that it does not have to write larger stripes than nescessary. In other words, a large write can be directly translated to a write to a large stripe on the sotrage system, and a smaller write can use a smaller stripe width. This can improve performance since it can reduce the amount of data written.
There are plenty of other areas where this integration is needed, including snapshotting, but I hope the above explanation explains that the layered model is not always good.Nothing stops an "authoritative, top-down organization" from taking all the open-source work done on Linux, and applying its own methodology to driving it forward; if that's more effective than what everyone else in the Linux community is doing, users will be more interested in adopting what they do with it (and, heck, once the transition occurs, the less-centralized portions of the community will probably follow along and start working on the "Neo-Linux" thus produced.)
Its true that revolutionary, rather than evolutionary, change is probably best driven by a narrow committed group with a shared vision and the skills to realize than a disorganized community. But there is no barrier to that within Linux; and between the occasional revolutionary changes, the evolutionary changes that the community is very good at will still remain important. With open source, you don't have to choose: you can have a top-down narrow group working on revolutionary changes (you can have many of them working on different competing visions of revolutionary changes, which, given the risk involved in revolutionary change, is a good thing), all while the community at large continues plugging away on evolutionary changes to the base system—and if once one of the revolutionary variants attracts attention, begins working on evolutionary improvements to that, too.
I've heard from people looking to port ZFS to the BSDs that it is a very difficult port, due to how tangled up it is with the operating system (Solaris) itself, and how much ZFS does for itself (volume managment, RAID, etc).
On one hand, this gives it some serious advantages when run on Solaris 10. But it also makes it difficult to port. I wonder if that is partially responsible for delaying OS X Leopard?
You don't seem to understand snapshots.
A snapshot works by creating a copy of the device, with the contents it had when the snapshot was created. If you make a snapshot of
Why would you change anything over? Snapshots are temporary. You snapshot your drive, use the snapshot to create a consistent backup (or whatever), then destroy it.
Normally you won't keep a snapshot around for long, as they're maintained by keeping copies of modified blocks, and that takes space. Unless you have enough space for fully duplicating the device you made a snapshot of, you won't be able to keep it around forever.
Maybe my entire view of things is wrong, but isn't strict layering responsible for most of the things that set Linux apart from less-efficient and less-secure operating systems? Isn't layering what allows the same exact operating system be a high-performance server or a normal work station? I point out the latter because without layering, things like Windows can "disable" a lot of things that are all tied together, but never really remove many things completely since ... whatever.
I guess what I'm saying/asking can be summarized: isn't layering one of those really-important things to Linux that shouldn't be violated? Reading the summary sounds like "In order to make Linux more Windows-like, we need to violate the things that makes Linux much more of a proper layered OS than Windows is."
The Windows installer also talks about partitions. It asks you to [c]reate, [r]emove, or format a partition.
It actually offers more options with more terminology than the Ubuntu/Kubuntu installer.
The Ubuntu installer offers you install options:
"Simple - use free space"
"Simple - overwrite whole disk"
"Advanced - Setup your own partition table"
Ofcourse most users can choose one of the simple options. The advanced one has a nice GUI to resize partitions and basically do everything from a GUI.
In Windows its a bit more complicated than that, as explained above.
So nice try, but even partition-wise, Ubuntu/Kubuntu have easier installers.
Uh, Unices aren't that easy to hack if you set it to block connection attempts from outside sources that get the root password wrong say..5 times. You can't password crack in that time. Then again, Macs and Ubuntu disable root by default so they have to guess username AND password. So, no, Vista's probably not more secure than Unices. Linux and Vista have the SAME problem. Drivers for both are in limited supply.
look! it's a bird, it's a plane, it's....a girl? yes, a girl browsing Slashdot on Linux
You hit the nail on the head: 'something being worked on' (project) is NOT the same as 'something ready for use' (product). Note to mods: parent deserves credit for making this point.
However, there is a large overlap between 'project' and 'product'. In-development-systems can be quite useful, and when are products really 'done'? Look around in your average household store. Many simple items (like paperclips) may have evolved, but their basic form is the same as the 1st day they where conceived. Read: the very first incarnation of a paperclip may have been rude, but no less useful than the matured, modern-day version. For complex products: try and find one where every aspect of its use, from production, marketing, distribution, everyday use, to how it is discarded/recycled, is well-thought through and 'just works'. Good luck.
Basically: things that are both complex and well-engineered (in every aspect) are rare. 'Project' or 'Product' is not the same, but only a label. Which one applies, depends on your point of view.
Take some projects, add packaging, marketing, support, ask money for the whole, and voila: a product. See IBM, Red Hat, SUSE for example. Whether a Linux kernel or a Perl binary shipped by them is a project or a product, only depends on how you use it. If you're a developer working on it, it's your project. When you're selling DVD's that include these in bulk, the same thing becomes a product.
I've used Linux for different purposes starting around '94/'95 (normal desktop use these days, Windows is history for me), and I can assure you: it far exceeds what one might call 'consumer grade product'. That Linux has maybe around 1% market share among ordinary PC users, has nothing to do with quality or technical limitations, but everything with marketing, industry inertia and historical reasons.
6. "Top N reasons why Linux sucks" lists posted anonymously on the web by people who haven't touched a Linux machine since 2001.
0 1 - just my two bits
I think you'll find that it is you that doesn't understand what a snapshot could be. Take a look at ZFS, try it, and see if you think of snapshots the same way again. In ZFS, a snapshot can be promoted to a clone, which is a writeable copy of the original filesystem, sharing unmodified blocks using a copy-on-write algorithm.
This is increadibly powerful and useful. For example, a single master 'image' volume can have customizations added for specific purposes. This is useful in desktop deployment, iSCSI or NFS network boot, etc...
Would you expect a 'first class' writeable clone to have a name like 'dev/mapper/snapshotted-hda' or 'dev/hda.1'? Which one makes more sense? Why would the original have a special name, when the clone is identical?
It's this kind of narrow 'snapshots are throwaway' thinking that causes artifical limitations in APIs and operating system design that serve no real purpose.
I maintain a Linux file system which is typically used across various kernel versions, including 2.4.x. Yes folk's 2.4.x is still used to ship new products. The changing interface makes for Fun-And-Games.
The VFS to file system is not particularly clean as you need to do pretty ugly things like increment page counts etc within the file system. Much of this is done to enhance performance, but could probably have been done better (ie. preserving a clean interface without real performance compromises).
Engineering is the art of compromise.
LVM has this already. CONFIG_DM_SNAPSHOT in the kernel config.
If you use LVM, then all devices you put a filesystem on are in
But they aren't identical. LVM works with block devices, it doesn't know about the filesystem. If you do a bit-by-bit comparison of the original device with its snapshot, if the original changed, then there will be differences. The snapshot contains the data it would if you unmounted the FS and make a copy of the device.
The direct quote is "I've long seen the Linux community's inability to design, plan, and act in a holistic manner as its greatest weakness."
You can see the meaning has been completely changed in the summary from one of positive criticism to one of arrogant condemnation.
Through this change, we can see the posters true feelings, feelings that are shared by many in the Linux community. That is to respond immaturely and get all bent out of shape if somebody builds anything that doesn't follow the "Linux philosophy".
The Truth. Both Linux in general, and ZFS are amazing, and powerful tool. One of best philosophy I've encountered is "use the right tool for the job".
Nobody is forcing Linux devs to port ZFS, or even use, or even think about it. The only reason this is an issue, is because many in the Linux community realize how powerful ZFS is, and they're subconsciously pissed off that they can't have it. So they respond like a 3rd grade bully by attacking it in a self defeating attempt to minimize its importance.
You don't seem to understand snapshots
:-)
/dev/hda at 12:15, then you'll get /dev/mapper/snapshotted-hda as it was at 12:15, while /dev/hda will continue being possible to modify... Why would you change anything over?
/dev/hda directly when it is snapshotted. You must access /dev/hda through some other device and that some other device must located in the /dev/mapper directory. No wonder you apparently mixed up what is a snapshot and what is being snapshotted - the way we currently do this in Linux is quite unnatural and is a wide open invitation to such confusion, not to mention a pointless makework project for system administrators.
If you say so
A snapshot works by creating a copy of the device, with the contents it had when the snapshot was created. If you make a snapshot of
Because with the incumbent volume management strategy you may not continue to use
Have you got your LWN subscription yet?
I would expect this shoddy driver support out of ATI, since they have always been pretty disappointing. But nVidia is a true disappointment, since their driver support had always been top-notch until now.
As a PS...
For Vista - NVidia and ATI had to write the entire driver from scratch. From GPU Scheduling, RAM Virtualization to tons of other Vista features of the WDDM, make the leap quite significant.
However the thing people don't see to understand, even if you have Video card that has a crap driver available for it, just install the XP driver. You lose the WDDM and Aero concepts, but Vista works just like XP and will give you back the same quality and experience for Video.
So all the people whining about not moving to Vista because of the video driver problems are really not too bright. They can be running the same XP driver on Vista that they are using now, but have the other features of Vista. Then when NVidia and ATI get all the bugs out of the Vista driver version, move up to the cooler new driver features Vista offers in the WDDM Video subsystem.
Having a coherent design is what allows people to reason about the system as a whole. Breach the design, and suddenly nobody can say anything about anything without tracking down and understanding all of the code involved. Commercial companies do this all the time when playing catch-up with rivals, because they have to retain their customers at all costs, but they suffer terribly for it in maintenance costs and stability. There's no reason in this case for Linux to take the fast, self-destructive route. Linux can wait for a coherent solution, even if it is years coming.
I'd love to used Linux as a desktop. I just need a little help.
I even enjoy spending time tweaking my desktop computer, from back in the days when memory came in 16k chips, IRQs had to be tediously managed, and squeezing every drop out of 640k was fun. But try as I might I have yet to get a stable, visually appealing, or useful version of linux on any of my previous 3 computers. Why? Because I can't even get a minimally functional system running, and give up before I get to the tweaking stage.
Major problems I encountered which I spend more than 1/2 an hour working on each: picking a distro, much harder than you think for the non-initiate. KDE vs Gnome? Utterly crappy (ie Mac 6) video support without special do-it-get-it-complile-it yourself drivers. Can't install video drivers, I didn't install gcc (silly me). Can't install video drivers, I'm missing some contingencies. Can't install video drivers, I didn't install the source code for the kernel (silly me). Multiple conflicting versions of drivers and conflicting advice about which one to use. Multiple conflicting instructions on how to install said video drivers. Video driver installer has reams of text output, some of which are error messages. Based on more advice, appearantly these error messages may or may not be normal and may or may not be why I never got good video output. My sound card stopped working. I still don't know why.
Valuing my time at a paltry $50 an hour, I could have easily bought a newer better system with WinXP on it and then taken my wife out to dinner with the remainder.
If anyone can recommend a distro that will run, out-of-box, on my Dell e1505 with an ATI x1400 graphics card and Creative Audigy soundcard, then I promise you I will excitedly hunt it down and intall it, I really do want to switch to linux, the visuals I've seen other users have is incredible.
Unfortunately the fact that I have to ask such a question really shows how linux in general is completly unprepared for the desktop market. Prove me wrong and recommend a distro.
PS - please, no berating, calling-of-noob'ing, or general fun making at my expense. I really honestly do want help, and Linux people have tried to help me in these ways before. (they haven't proven helpful yet)
Of course I don't agree.
I'm doing a long term comparison test between Fedora Core 6, and my Knoppix remaster,, both installed on the same machine, a HP Pavilion 8250, maxed out on memory, and with a dual hard drive setup, one 2 GB for MSDOS to run my loadlin menus, and for GRUB in the MBR, and the main hard drive, a 160 GB for both linux installations to use.
My Knoppix remaster, Rapidweather Remaster of Knoppix Linux runs from a "tohd" partition, with a really big "persistent home" partition, and a common swap. So, even though I have a nice "logo16" splash screen with a bright yellow boot prompt, I don't get to see it on a daily basis with the "loadlin" setup, only if I decide to run off the CD for some special purpose.
I have all of the fonts that I could possibly get from the Debian package servers, and I delight in showing off how well Firefox, for instance, displays web pages, compared to Windows XP (another box, with P4 HT and 128 MB ATI). The Fedora Core 6 installation does not quite measure up to either Rapidweather Remaster or Windows XP when it comes to the "font comparison".
I realized early on that I would need the fonts, no one is going to "get used to" poor fonts, once they see something better. The original Knoppix I started with, and the latest ones I have reviewed, do have what I would call "minimal" fonts, I would not be satisfied with.
Rapidweather
Rapidweather's Linux Screenshots.
They use C, a language from the same period, not C++.
Thank God for that. C++ is an abomination. It's not good at OO, it's not strictly procedural. Hell, it's not even clean.
They use an interface that literally emulates an ancient teletype.
Hey! Don't talk about GNOME like that!
Microsoft is to software what Budweiser is to beer.
"1. Fonts, they are simply not as good as Windows."
Maybe. But just now I'm writing this on a Linux desktop while a Windows XP laptop is near left. I really can't apreciate any significative difference. Maybe I lack good taste or something, but I can say that no people that saw my Linux desktop (neither this one at home nor the one at work -basically the same) said "oh, those fonts are so ugly!"
"2. Ease of use. Nobody has sat first time users in front of a linux desktop and watch them puzzle over what those multiple desktops do, or how to switch between them."
On the table to the left (that's left from my laptop) stays my girfriend's laptop I gifted her. She's musician and graduated on History (go figure her techy abilities) and she was simply amazed when she turned on her new computer and saw the pretty login screen (while eventually I teached her how to change it, and she in fact tried some variants she returned to the "original" one since "it's so cute"). And I still remember she was just in heaven when she discovered she had "four computers in one" (four desktops) instead of just one like those poor windows users ("they'll be green with envvy" were her words more or less). Obviously she doesn't use the command line for anything and still manages quite well on her day-to-day tasks and asks my help no more (well, much *less* in fact) than she did when she used Windows on her previous computer.
"3. Basic styling problems. Needless flickery redraws of desktops. Uneven and asymetric layouts, huge icons in some places, tiny icons in others. Isometric icons"
Again, my girlfriend doesn't seem to be so much affected by this (and, by the way, what the heck is an "isometric" icon? The only thing I can imagine is a family of icons that maintain their aspect ratio disregarding scale, but this do seem to me an advantage much more than a defect), nor does my on-her-sixties mother which is so happy with her Linux box (I doubt very much she's even concious she's using Linux -she knows there exists some "gadgets" known as "computers" and barely anything else) and her ability to play some card games and talk to her daughter few thousand miles away through IM.
"4. Lack of help, I try to save, it fails, where's the link to the help that tells me..."
True enough. But if you are trying to imply that other operative systems' help is of any use -cough- Windows -cough- I'll say that in my more than a decade of professionally dealing with computers (while I never did "pure" helpdesk I've been always more or less near to end users) I *never* saw the case that the including help was of any aid to any user to solve their problems. Not a single time. Never.
"5. I am not interested in your philosophy, assemble me a bundle of software that fits my needs regardless of whether than software fits your philosophy."
Good luck using any version of a Microsoft solution and its "bundle of software" fitting your needs. Do you really have all your needs covered out of Notepad and Minesweeper?
"If there is one thing I would suggest, get Ubuntu played with by ordinary grandma"
I *already* did the experiment out to the letter (you see, my mother doubles as a grandma too). And yes, she was quite confused at the begining even pointing and clicking with the mouse (it's not such an easy task for an old woman, did you know?). On one hand I can't see how pointing-and-clicking would have been any easier on Windows; on the other she manages now to do with the computer anything she was interested at (playing some easy games, using IM, ordering her photo collections, writing an odd e-mail...) and I honestly feel that her using Windows wouldn't make her experience any easier. And please, pay attention that I'm not even living in the same city so I really can't "babysit" her on the computer but the odd weekends I visit her. Oh! and the OS isn't even one of those "easy Ubuntus": she must be a hardcore hacker, since she's using Debian "Sarge". Yeah, she must be a hardcore hacker since now I remember her computer has been free of virus and spyware all this time, not as some friends of her that doesn't happen to use the same OS.
Most of all, to me, I am astonished that almost everyone talks 'virtualisation', VM, QEMU, Xen.
When it comes to filesystems, suddenly many seem to want to do everything on their own, on physical platters: partition, volumes/RAID, format. ZFS is a virtual filesystem, where none of such is physically needed. There is a nice http://www.opensolaris.org/os/community/zfs/demos
Of course, filesystem should be a black box, an object, instead of the user having to do low-level work. ZFS provides this, and more relevant: of course it needs to be cross-layered therefore.
Snapshots ought to be available easily, at any moment in time, without taking much space. ZFS does so, by only storing the changes and sharing the unmodified data. If you want to do so, you need an abstraction of the hardware. That is, crossing layers. Not to mention writeable snapshots.
Adding new drives without partitioning, slicing, formatting. Just adding to the existing pool. Inclusive striping being adapted automagically. This needs a cross-layer interface, right ?
The transactional filesystem guarantees uncorrupted data at power failures and OS crashes. If you do this across a pool of physical platters, you need operations across layers.
There is an interesting blog on the usage of ZFS for home users. It contains some good arguments, why ZFS is useful for Linux' Desktop Stride. You find it here: http://uadmin.blogspot.com/2006/05/why-zfs-for-ho
Last ot least, the online checking of all your data ('scrubbing' and 'resilvering') is a valuable feature for Linux (and the home user) as well.
To me it looks like, as of today, that about everyone liked the features of ZFS. Now, as it requires to break some old habits, suddenly we resist change and rather stick to older concepts.
As if GPLv2 vs GPLv3 was not enough of a threat to Linux, now we unashamedly permit a new-from-the-bottom-up filesystem to overtake us as well ?
No, it is not stupid. You seem to be suggesting that snapshotting should be something that can be done on an arbitrary block device. To do this, you would have to have this supported in the block device handling, and this could be *very dangerous* in some environments (GFS, for example, or other DLM-based clustered filesystems) and misleadingly useless in others (snapshot one volume in a RAID 5 array). To make this work, I think it is best to handle snapshotting on the bottom-half of the filesystem (the inode layer->block device interface). However, there is some use in having it handled by the LVM (in that it allows you snapshot logical block devices rather than filesystems).
/dev/ location of LVM volumes to /dev/lvm/... Makes for less typing and more transparency. Makes the entire picture both cleaner and clearer.
I am not saying that the current system is perfect (no system is, and one should always strive for improvements), but I don't think doing snapshots of arbitrary block devices is a good way to handle it.
My list of things to improve include:
1) Change the
2) Make sure that *all* the newbie Linux documentation covers LVM.
LedgerSMB: Open source Accounting/ERP
One legitimate complaint is the poor state of integrated RAID support in the linux LVM. Yes, the LVM can mirror logical volumes now, but it is very klunky (I miss AIX LVM). Creating PVs on top of md devices is tedious and error prone (because you often need to split physical devices into multiple partitions to avoid resyncing the world). The LVM should at least support RAID 0 and 1.
Another complaint is the lack of consistent high level utilities for file system admin. On AIX, one command allocates a logical volume and creates a filesystem on it (or you can do the steps separately for greater control). Linux makes you create the LV, then create the filesystem. Worse, linux used to offer e2fsadm to resize a filesystem and the underlying LV. Now, you have to run lvextend THEN resize2fs - or the reverse if shrinking (and you had better type those sizes right). While it is nice to have access to raw LVs for some things, I really don't want to have to manually compute volume sizes - with potential data destruction in case of mistakes.
Most recently, it has been the package management. I have been all but forced to use the "commercial" RedHat up at work, and I still cannot believe that Redhat uses a lame package manager that requires you to "solve your own" dependencies.
They don't. Up2date resolves dependencies.
Redhat is another problem. rpm doesn't have the smarts to do anything for you. If you want any kind of 'immediate' commands, you have to 'yum' them. This isn't acceptable in a corporate environment.
Well, sure - but that's because the whole "dependency hell" thing Linux has developed isn't really acceptable in a corporate environment, not because of anything specific to yum. It's not like Debian is meaningfully different in that regard.
yum is a bastard that is excluded from RedHat so they can maximize acceptable up2date profits.
Yum isn't "excluded" from Red Hat (indeed, RHEL5 has replaced up2date with yum).
I could really care less if RedHat goes out business or not.
Considering how much kernel development they fund and how important their product is to adoption of Linux in the enterprise, you probably should.
Debian is at least 1 full generation ahead of RedHat. Redhat Enterprise is still redhat 9 with updates.
Just like the current version of Debian is the previous version with updates, you mean ?
Sorry, but I can't agree with your reasoning. To explain, let met set out a few realities of software development, as I've personally come to see them after some years as a developer:
Now, these are obviously blanket statements, and no doubt there are valid exceptions to each rule. Indeed, the rules themselves seem almost contradictory, though I think that is just an illusion: what they really tell us is that balance is required, both in the degree of concentration of effort vs. parallel development, and in the degree of future planning and generality vs. the efficiency of developing what will actually be used in the end.
Now, take a look again at the argument you gave in the parent post.
If you have 100 different ideas for ways to solve a problem, then go ahead and develop 100 different solutions to see which work best. But in reality, do you really, or are there only really a relatively small number of solutions, but many implementations of each with few real differences?
OK, let's assume there really were 100 unique approaches, and that in practice 5 of them turn out to work best. Did the other 95 learn something developing their failed alternatives? Perhaps, but they might have learned something helping to develop the successful alternatives as well. After all, if so few of the ideas really worked out, would it not be better to study those and the ideas and techniques of the people behind them?
You also suggested that the 95 would have given something back to the community. But would what they gave back have much value? Again, it seems unlikely that if 5 different solutions were all viable, the other 95 would really offer many further ideas in terms of high level design or general approach. And again, if they did, perhaps those same good ideas could have made the better solutions even better still if the development teams had compared notes earlier, giving a best-of-both result. The 95 might also have some neat implementation tricks, but as I suggested above, in reality it seems very rare for one project to borrow code from another in this way unless the code in question was specifically developed as a self-contained library, in which case it's not really specific to one of the 95 failed attempts anyway.
It's not hard to see that a small number of ideas, perhaps 2, perhaps 5, might offer genuine pros and cons, and with a concentration of development effort they might be able to learn from each other's experience and systematically share code for common functionality so that all benefit. But really, I don't see this happening at a micro level. It has to be mac
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.