Having done the whole "Linux from scratch" thing as a learning experience, I can tell you that building a complete Gnome installation takes at around 3-5x longer than KDE and is much more difficult. This was 4-5 years ago, but the situation has gotten worse from casual observation of the Debian packaging.
One of the biggest differences between KDE and Gnome is that KDE's use of the Qt library dramatically cuts down on dependancies. Gnome requires use of dozens of libraries to match the functionality of Qt and this complicates the build process.
Frankly, from a developer perspective, I don't think Gtk/Gnome libs have quite kept up with Qt in terms of overall quality and I'm not sure how they can be expected to. Qt is heavily supported commercially. There are people being paid full time to add features, improve performance, and write top quality API docs. Gnome expends much effort maintaining its own libraries. It's a shame that KDE and Gnome do not both use Qt. It would eliminate almost all of the compatibility issues, save memory on hybrid desktops, and allow them to compete on things that really matter like UI design. (where there are legitimate arguments on both sides) But, unfortunately, Qt began it's life as a less-than-Free piece of code. As a result, the Gnome folks rightly avoided it. But then they continued their own efforts even after Qt went GPL.. Now there's even a GPL full version for Windows, so the cross-platform argument is totally shot.
FWIW, I'm not trying to bash Gnome, but I do think there is some re-evaluation in order. Competition is good, but wheel re-inventing is usually not.
The best defense against this is probably to use the "open source" concept where it's most useful: In making public the details of the algorithms used.
Yes, this is an excellent point -- and one that I've made myself in the past. In fact it goes beyond just code and algorithms. Open Source projects can also help to pre-empt software patenting by fully disclosing their future plans -- even those that seem "pie in the sky" at the time. I'm even talking about statements like, "wouldn't it be neat if we had XYZ feature that would do X, Y, and Z using this and that methods." Ideas that stick can be expounded upon further by specification and eventually code if there is enough interest.
The only real defense against a patent lawsuit is to show "prior art".
At this stage, perhaps yes. However, in the future, software patents may be challenged on a Constitutional basis. If it becomes obvious that Open Source has largely taken over the software industry, this will further boost the argument that software patents are of no benefit. It will be hard for courts to rule that they meet the "to promote the progress of the sciences and useful arts" requirement. Hopefully the patent office will be reformed before it gets to that point, but I'm not holding my breath.
I was gonna suggest the same thing.. it could be a webcam or a cheapo digicam of similar res to the screen itself. Well, you all heard it here first! So when Apple decides it deserves a design patent for "Technique to Create a Real-Time Illusion of a Transparent Monitor Screen" we can all point to the prior art.:-)
All the Open Source community needs is its own patent ammunition to protect itself.
Maybe.. But this absolutely cannot come in the form of patents themselves as this would be hypocritical and could dramatically weaken the chances of ever getting software patenting invalidated. The "ammunition" may possibly come in the form of OSS licenses that state that the licensee loses all rights to use and distribute the covered software for free if they engage in a software patent related lawsuit against any OSS project. Whether that would hold up in court I have no idea. I'm not a lawyer, but I'm pretty sure the folks at the FSF have considered this idea and/or others like it. Assuming that it would fly legally, it's strength would rely upon sufficient demand for use of OSS covered by such a license. Unfortunately, at this point it would probably be just a nuisance for litigious companies and it would be nearly impossible to prove anything anyhow.
The best defense against bogus software patents is simply to overwealmingly sweep the software market with superior, Free, commercially supported alternatives. No doubt some failing proprietary software companies will turn litigious in the process. But we must remember that the bogus lawsuits will end when the money dries up. Longer term, once all the cards are in the hands of Open Source driven companies, it will be a trivial matter to change patent policy.
And yes, I agree with Mitchell Baker that funding is essential. Love of the work is a large part of the reason for doing it, but love of success and fame and fortune are also a big part of it.
Funding is essential for OSS to succeed in the mainstream. However, I'm sure that many in the OSS community would gladly settle for "love of the work" + "a reasonable full-time salary." There's plenty of money out there for the taking. We just need to be smarter about how we go about getting at it. Take OpenOffice.org as example. Nearly every business in the world would benefit if OO.org was improved enough to become a serious alternative to MSO. Yet I don't see a flood of companies coming forth to support it, even with the high cost of MSO licenses! Sure, there's Sun.. but that's one company and they have direct commercial interests. Why is there not more momentum for a project this important that has already come so far? I don't know the details of what goes on behind the scenes, but something just doesn't add up. If I understand the OO.org website correctly, the team has not really pursued outside funding. I think they need to re-evaluate the advantages of bringing more full-time developers on board and then do some serious funding drives to make that possible.
Firefox/Thunderbird auto-update is currently worth crap. Just download the new version and use the silent install option: ie.) Firefox_Setup_1.0.2.exe -ms
The same thing works for Thunderbird. Usually I think it deletes the old Add/Remove options. (or at least one of them..) This is the most convenient quick-and-dirty way to update a bunch of machines in a small Windows domain.. put that command in everyone's login script the night before.
Patents and copyright need to be drastically revised to compensate _only_ the actual creative work.
IMO, that's exactly what we need to restore balance. With the exception of works done for hire, which are typically collective, companies should not be allowed to aquire intellectual monopoly rights from individuals or other companies. There's simply no need for this practice. Contract law is perfectly adequate. Publishers don't need to hold the rights to works to do their job. They are middlemen and it is entirely unfair for them to hold all the cards. (And with the direction technology is headed, they won't even be necessary in the future.. which as we all know is what the **AA are afraid of)
Another thing that should be outlawed are these patent rights holding companies that buy up rights for peanuts and then use them to leech off of healthy, productive companies. If a company goes bankrupt and is liquidated, the patents should either be automatically nullified or re-assigned to the individuals who actually produced the ideas. (Patent reform itself, of course, is another whole issue..)
I've done netboot installs with over 7000 seats, in 500+ geographic locations..
Wow.. I've certainly never done anything that large. My experience was more on a "workgroup" scale.. 20-40 boxes. So I don't doubt you ran into quite a bit more difficulty! Did any particular thing get in the way of smooth operation? What technologies were used?
The point of the removable storage with local apps is to mitigate the "but i cant work if the server is down" problem.
Hmm.. what about replicated servers to spread the load and reduce the effect of an outage? Then have some hot backups ready to swap in if needed..
network booting sucks big hairy mooseballs. trust me on this, it absolutely, positively sucks the big one.
I've done Linux network boot installations before and they work just fine once configured properly.
local boot into minimal OS, local apps on removable media, local data on removable media, remote apps on servers, and remote data on servers.
Replace "local" with "locally cached" and I'll agree with that statement. Who wants to have to go around updating hundreds of removable media devices every time the OS or certain apps change? Putting everything on the network is every administrator's dream. With OSS, it's even better because there's no seat-counting licensing hassles.
Indeed, the PC as a personal data island is dying. We'll see diskless workstations that network boot Linux/BSD/whatever and are used primarily to run a somewhat evolved Mozilla or Konqueror web browser supporting SVG, CSS3, XForms, etc. Most business apps will use rich-web, standards-compliant interfaces that feel no different than native clients -- except that they will be much better integrated than anything we've seen up to this point. Office suites will have been obsoleted by web-based document management systems, a component of said integrated business apps. Native apps will still be used as needed.. graphics, multimedia, etc. But they'll all be Open Source and loaded from the network. Every workstation in the office will thus have a complete and uniform collection of software available. (Unlike today, where employees must usually beg for a license of Photoshop, Illustrator, etc.)
At home, it'll be very similar.. every family member will have their own wireless terminal of sorts. All software and storage will be centralized to a server in the closet. Solid-state internal storage will allow for disconnected operation on trips, etc. but internet access will be so ubiquitous that you'll still be able to access your home web-based content portal.
Right idea.. wrong platform, wrong standards. We'll see diskless workstations that network boot Linux/BSD/whatever and are used primarily to run a somewhat evolved Mozilla or Konqueror web browser supporting SVG, CSS3, XForms, etc. Most business apps will use rich-web, standards-compliant interfaces that feel no different than native clients -- except that they will be much better integrated than anything we've seen up to this point. Office suites will have been obsoleted by web-based document management systems, a component of said integrated business apps. Native apps will still be used as needed.. graphics, multimedia, etc. But they'll all be Open Source and loaded from the network. Every workstation in the office will have a complete and uniform collection of software available. (Unlike today where employees must usually beg for a copy of Photoshop, Illustrator, etc.)
"Thin clients" will primarily not have local storage, aside from removable media; otherwise, they will be similar to current PCs, because it is necessary or cost-effective to do everything else per-client.
Precisely.. this is the part where Sun went wrong and Gates simply doesn't get. "Thin client" does not necessarily mean "200Mhz. processor and 32mb RAM running as a remote X terminal." That attempt indeed failed miserably as a mainstream solution. It's all about network storage and ideally network booting as well. (Though I would not be surprised to see solid-state local storage for caching and disconnected operation..)
Of course, this is all quite contrary to MS's plans for the PC Desktop, where an (expensive) OS platform is still relevant due to shunning industry web standards and pushing their own proprietary equivalents (XAML, Avalon, et.al.) I predict this will ultimately fail because commoditization won't have for it.
UNIX ceases to be UNIX when it doesn't feel like UNIX anymore.... Webmin presents none of these things. It is therefore not UNIX.... I am vehemently against even the mere dilution of anything UNIX.
Tools like Webmin can be installed and removed. They're optional. They're not part of the system. You can use them for quick and dirty changes and use your favorite shell and text editor for everything else. You can use them as training tools for new admins so they can get used to the configuration needs before they see what's really under the hood. So I'm not sure how you feel that the mere existance of tools which make Unix easier to admin for the majority somehow take away from its power when you use it. Look at it this way: We who are the old school Unix junkies will always be in the minority because most people simply aren't smart enough to do things the way we do. But would we rather them use Windows or use Unix with a candy-coated shell that we can easily peel away if we need to fix their machines?
I simply do not desire to wake up one day and find that someone has taken away everything I recognize as UNIX, and turned it into something which is only usable with a mindless point-and-drool interface.
You keep using words like "only usable" and "taken away" but nobody is doing this or even attempting to do this -- with the exception of MS who has done it already, but not to Unix.
I am particularly opposed to any changes that consist of a database for configuration data, even if that database does successfully masquarade as a directory tree.
You could easily call the/etc filesystem a "database." It's just not as granular as breaking large files down into many smaller ones. We're talking about the difference between whitespace and filesystem nodes for separating options. It's the same data. It's the same schema. It's just stored with more pointers.
The world is currently cursed with the misuse of complicated databases, where they present no clear advantage over human-readable text.
No doubt there are many examples of databases gone wrong -- complication that adds no value. In the vast majority of cases, however, it's not that flat text would have been ideal. It's the fact that the database designers didn't really think about what they were doing and so the result became worse than just using flat text.
Because in order to use that database, I need interface software. And in order to use that interface software, I have to abandon the UNIX ways of doing things that I know and love.
By definition, passwd is a database. You can edit it by hand or you can use an interface like adduser. But you would certainly not argue that the person who wrote 'adduser' is out to destroy the Unix way of doing things.
Unless you've got actually got something substantially better (and believe me, it's been tried), please focus your efforts elsewhere.
Do you really honestly believe that there is no room for improvement in our "Unix" way of doing things and that it will exist forever? And therefore we shouldn't try anything new? I mean.. I'm sure there were folks who swore by hand wiring their computer's logic because it gave them more control than early micro-chips. But there's a certain over-arching concept in the whole world of computing that abstraction eventually makes technology more powerful. Lets say that a new generation of admin tools actually works at some point. Suppose it actually becomes much faster, safer, and powerful to configure your Unix system from a GUI. You can accept this and say to yourself, "well.. this does actually work.. and now I have more free time to try completely new things." Or you can say, "Heck with this.. I'm doing things the old way even if they are inferior" and eventually lose your job as everyone else moves on. I'm not claiming this is just around the corner, but it will
If everyone is off on some XML tangent, that must mean that everyone hates it.
Fortunately everyone hates XML for system admin and that's not what Elektra is proposing.
So what? They're different programs, written by different people, and doing different things in different ways. Of course they use different file formats for configuration.
Elektra is not an attempt to change the way applications are configured. It is only an attempt to create a standard for how that configuration is stored so that it is more easily parsed. It doesn't force any radical change upon anyone. And, in fact, it would be trivial for programs to support both config formats as a compile-time option. Elektra is little more than placing each config line in a separate file and using filesystem hierarchy in place of indents, curly brackets or other means of designating blocks.
Yes. This is why they're called *different distributions.*
Variance in filesystem locations is not what gives value to having different distributions.
Would someone PLEASE show me a video driver which requires an Apache plug-in?
The text you quoted was giving multiple examples, not saying anyone would try to combine these things.
And ISVs don't want their job made easier, or else they'd find themselves without one. Next.
I suspect this is the root of your distaste for making *nix OS'es easier to manage/configure and the basis for the irrational arguments you are making. Consider this.. there will always be jobs for ISVs because there aren't that many folks smart enough to do the job right. You still have to understand the options you're setting whether you're using vi or a GUI interface. A new generation of admin tools will simply enable you to a.) handle more customers or b.) do less work.
Shucks. You mean that HP/UX is different from Solaris?
The point is not that OS'es can be made to be the same or use the same options. The point is that if everyone used the same config storage schema, it would be much easier to learn and keep track of multiple platforms / distros. Again, I think you're reading into their proposal too much.
That's why they're self-documenting and human-readable.
And also messy as heck, thereby reducing readability.. If you put all the information necessary to properly document a config schema in the file itself, there'd be a page or two between each option in many cases. Typically, many details are left out, forcing the admin to reference multiple external documentation anyhow -- there goes the self-documenting part. And how many times have you configured most of the software at the end of the file and then had to go back later and dig through the commented out examples because you forgot the syntax? And then a new version of the software changes some options and crap.. now you have to merge your messy config file with a fresh version with up to date comments. (But by this time you've probably given up on the self-documenting part and just deleted all the comments anyhow to make your settings readable)
Backups, backups, backups. Has nobody yet learned the purpose of a proper *** backup regime? It's not just to recover from hardware failure, but to provide a window into the past.
Backups are one option.. so is CVS. But how many times do you change more than one option per file per backup cycle or CVS commit? I agree this is one of the weaker arguments for Elektra, but it would increase granularity of revision records slightly. With admin tools that employ optional XML meta-data (stored in separate files, not part of the config!) you could easily implement a full history of changes for every option in the hierarchy. You could even devise an easy way of doing rollbacks of any change or groups of changes at any point in history without having to hastle with manual merging.
Webmin, and all of its evil little friends, consists of a crutc
However, I will totally grant that a *major* innovation that will account for a large improvement in reliability, productivity, interoperability, and lower costs would catch a lot of eyes.
I don't see OO.org as an innovative project; I see it as a transitionary project. There's really not much innovation left within the current "word processing" paradigm. After all, it's nearly 30 years old now! So I see OO.org as a temporary free alternative for while the really innovative stuff is being worked on. I say transitionary because OO.org is a good way for people and businesses to begin migrating their documents out of proprietary formats into something future-proof. The future is web-driven document management systems where content and presentation are cleanly separated and all information is stored in a database instead of scattered throughout local and network filesystems in various formats. I'm not talking about the hack-job web groupware solutions available today where everything is done in a regular word processor and then uploaded to some intranet site. I'm talking about all work being done within a highly integrated, rich-web interface.
However, going back to my first point, how do you force that innovation along?
You put highly visionary people in charge of teams of highly motivated programmers who agree with the vision. (-: Have you noticed how fast the Blender3D project is moving along? Perfect example.. it's new, it's exciting, and everybody wants to help out. Not so many people are really that excited about doing OO.org development. It's not the cutting edge, it's pretty dull and boring work, much of it is re-inventing wheels. Yet OO.org is still very necessary at this time, so my thanks and appreciation to all those who are slugging away doing the hard work for the benefit of us all!
I believe people are probably already trying to do, but coming up with brilliant ideas is a little harder than sitting down and deciding to come up with brilliant ideas.
Software is a very evolutionary field. There really aren't any major breakthroughs.. just a bunch of baby steps of progress. Now, there are paradigm shifts, in which the combination of available technologies enables new approaches to old problems. (Such as my prediction that rich-web intranet apps will obsolete today's concept of word processing..) But it's really unfair to say that Open Source projects are "just copying" proprietary software because that proprietary software had a long history of copying other proprietary software and making small improvements along the way. It's really no different. (And it's why software patents are so bad for everyone. Even ol' Billy G admitted that back in the mid 90's.)
This is very similar to the modern/proc and/sys filesystems in Linux. When I talk about XML meta-data, I refer to the fact that, for example, at the root of "system/users" you might have a file "config.xml" which describes all the valid options and values in the "users" hierarchy. This would allow for really slick GUI admin tools, but would not compromise the ability to configure the system by hand if desired or necessary.
Correct.. external features, not internal technology, are what drive public acceptance. Firefox needs to continue to offer things that IE does not have. However, it should be noted that standards support can create public interest through superior webpages. How many people over the years have downloaded Flash because of the features it adds to their browsing experience or because certain fancy sites required it to display all content? (it's a pity Flash was not standards based.. like SVG + DOM + JS, which will replace it)
Implement something as powerful as Windows Forms (or it's Linux equivelent). It's the thing Microsoft fears the most
Mozilla already has XUL, but it's not a W3C web standard; it's a Mozilla standard. XUL will be replaced eventually by XForms, SVG, CSS3, and other true web standards. From all indication, Microsoft does not plan to implement XUL or the next generation of industry web standards. Why? Because they are creating their own proprietary, incompatible standards such as XAML and Avalon. These are features of Longhorn which borrow tons of ideas from XForms, SVG, XUL, etc. but will only work in Windows. Microsoft hates open web standards because they allow efficient competition. The more powerful web standards become, the less relevant desktop platforms become.
You're almost on the right track regarding the threat web technology poses to MS Office marketshare. However, the threat is not web browser equivalents to an office suite. And it won't entirely be the result of OpenOffice either. The real threat to MS Office is a shift in paradigm away from word processing altogether. In the future, most office workers will not create word processing documents in the sense of files saved to some network share. They'll enter lightly-formatted textual information into a web-based content management system and all layout will be taken care of automatically. After all, secretaries and businesspersons are not professional typesetters. Why should they have to worry about such things? And it should be easy to imagine how much easier revision control and document workflow will be with all information stored uniformly in a database rather than scattered in multiple file formats throughout filesystems and groupware messaging systems.
What about the other components of today's office suites? Well, spreadsheets are already dying out as real database technologies become cheaper, more powerful, and more accessible. Presentation tools are already highly competitive, with many 3rd party alternatives to PowerPoint. There's plenty of room here for new technologies and approaches. Furthermore, presentation documents are often one-time-use so there's much less need for strict backwards compatibility.
Leave/etc as it is. It works. It's done the right job now for coming on 30 years.
It works. It's far better than Windows registry. But it can be improved and this is what the Elektra project mentioned in the topic is all about. Unfortunately, it appears that nobody posting to this thread has actually read about the idea. (as usual.. skip the article and jump into a flamewar) Everyone just assumes the only alternative to/etc is some sorta hideous XML jungle.. or a special daemon reliant mess like GConf that adds no value.
Why do you desire to take away my tools and replace them with the moral, conceptual, and visual equivilent to regedit? Is one coder's time worth the agony of the entire unix-using world?
I don't know how everyone got off on this silly XML tangent. Head over to http://elektra.sf.net to find a Unix-admin friendly alternative to/etc that actually makes sense.
If you want to change/etc you are going to have to convince vi or even ed users like me. xml ain't gonna do it.
I fully agree. Head on over to Elektra's website, http://elektra.sf.net, and ponder the alternative of breaking configuration down into a standard file hierarchy much like/proc or/sys.
And it would be trivial to re-combine everything into a single list for rapid text editing.. just traverse the tree. I'll bet an editor for this would be mere weekend project in Perl.
XML is the wrong approach, partly for the reason you mentioned. Head over to Elektra's website, http://elektra.sf.net and find out why their idea is so much better than both/etc and XML alternatives.
Now one thing you must consider, however, is that XML meta-data would be a good thing. It would allow you to edit your flat files in an Elektra hierarchy any way you wish, but it would also allow for rich, self-describing config trees easily managable with a rich GUI admin tools.
It's an improvement, but Elektra plus optional XML meta-data is much more powerful and flexible. Forget new APIs and use our trusty filesystems instead.. it makes perfect sense. Seriously.. head over to http://elektra.sf.net and read all about it! (:
OSS is about choises, and/etc really highlights this. People have different ideas on how apps should be configured
OSS is about choices. But not all choices bring value to the community. As a long time Linux admin, I can tell you that peoples' different ideas on how apps should be configured does NOT bring any value whatsoever to Open Source. It does quite the opposite. We absolutely must find a compromise and bring sanity to the situation.
So far, Elektra is the best compromise. It doesn't require any new tools. It doesn't require any drastic changes in most software. It doesn't create any single points of failure. It retains the human readable and human editable nature of/etc. It makes security more granular. And most importantly, it opens the door for a new generation of GUI admin tools that will make Unix administration accessible to the masses of existing Windows admins who don't have time to re-learn everything they know. Of course, it'll also improve the lives of seasoned Unix admins as well. At least those who value their time..
to clear/etc/ you would create another one that would need programmers to comply to that?
Elektra-style configuration could easily be phased in over time. That's part of the beauty and simplicity of it.
wouldn't it be actually easier to get them to place stuff in/etc/ so that they're logically placed and findable?
It wouldn't solve the problem -- which is that it takes too much time and effort to administer a system using today's/etc mess. It has very little to do with logical/etc organization. It has everything to do with trying to figure out what the options are, what the valid values are, and how to integrate the slew of packages necessary to make a working system for real-world needs. Yes, the real world needs standard, Open Source GUI admin tools.
The Elektra design is on the right track. The only thing it is missing is optional XML meta-data that can describe the key-value hierarchy to a new generation of admin tools. Everything else is perfectly taken care of by the filesystem. Imagine if, instead of editing long, heavily commented config files, you could browse through a logical hierarchy of the options. Whenever you select an option, a side panel lists the valid values, describes their purpose, and gives usage examples. Upon edit, the admin tool validates the value entered and logs the change with a timedate stamp. If you want, you can add notes too.. these are stored in your home directory or optionally within the metadata as well. (though a different file)
Beyond configuring individual packages, switching a standardized config hierarchy would enable a new generation of intelligent, modular admin tools. As example, imagine if the software could automatically "wire up" all the tools needed for a complete mail or file server. You choose what packages you want and the admin tool looks up a default "recipe" for making them work together. Then all you have to do is configure the specifics for you installation. Sure beats endless HOWTO's for every combination of Linux distro, MTA, IMAP server, webmail, spam filter, virus filter, etc.
I've been administering Linux for 8 years now and this would absolutely be a dream come true.
Slashdot Mirror
Having done the whole "Linux from scratch" thing as a learning experience, I can tell you that building a complete Gnome installation takes at around 3-5x longer than KDE and is much more difficult. This was 4-5 years ago, but the situation has gotten worse from casual observation of the Debian packaging.
One of the biggest differences between KDE and Gnome is that KDE's use of the Qt library dramatically cuts down on dependancies. Gnome requires use of dozens of libraries to match the functionality of Qt and this complicates the build process.
Frankly, from a developer perspective, I don't think Gtk/Gnome libs have quite kept up with Qt in terms of overall quality and I'm not sure how they can be expected to. Qt is heavily supported commercially. There are people being paid full time to add features, improve performance, and write top quality API docs. Gnome expends much effort maintaining its own libraries. It's a shame that KDE and Gnome do not both use Qt. It would eliminate almost all of the compatibility issues, save memory on hybrid desktops, and allow them to compete on things that really matter like UI design. (where there are legitimate arguments on both sides) But, unfortunately, Qt began it's life as a less-than-Free piece of code. As a result, the Gnome folks rightly avoided it. But then they continued their own efforts even after Qt went GPL.. Now there's even a GPL full version for Windows, so the cross-platform argument is totally shot.
FWIW, I'm not trying to bash Gnome, but I do think there is some re-evaluation in order. Competition is good, but wheel re-inventing is usually not.
The best defense against this is probably to use the "open source" concept where it's most useful: In making public the details of the algorithms used.
Yes, this is an excellent point -- and one that I've made myself in the past. In fact it goes beyond just code and algorithms. Open Source projects can also help to pre-empt software patenting by fully disclosing their future plans -- even those that seem "pie in the sky" at the time. I'm even talking about statements like, "wouldn't it be neat if we had XYZ feature that would do X, Y, and Z using this and that methods." Ideas that stick can be expounded upon further by specification and eventually code if there is enough interest.
The only real defense against a patent lawsuit is to show "prior art".
At this stage, perhaps yes. However, in the future, software patents may be challenged on a Constitutional basis. If it becomes obvious that Open Source has largely taken over the software industry, this will further boost the argument that software patents are of no benefit. It will be hard for courts to rule that they meet the "to promote the progress of the sciences and useful arts" requirement. Hopefully the patent office will be reformed before it gets to that point, but I'm not holding my breath.
I was gonna suggest the same thing.. it could be a webcam or a cheapo digicam of similar res to the screen itself. Well, you all heard it here first! So when Apple decides it deserves a design patent for "Technique to Create a Real-Time Illusion of a Transparent Monitor Screen" we can all point to the prior art. :-)
All the Open Source community needs is its own patent ammunition to protect itself.
Maybe.. But this absolutely cannot come in the form of patents themselves as this would be hypocritical and could dramatically weaken the chances of ever getting software patenting invalidated. The "ammunition" may possibly come in the form of OSS licenses that state that the licensee loses all rights to use and distribute the covered software for free if they engage in a software patent related lawsuit against any OSS project. Whether that would hold up in court I have no idea. I'm not a lawyer, but I'm pretty sure the folks at the FSF have considered this idea and/or others like it. Assuming that it would fly legally, it's strength would rely upon sufficient demand for use of OSS covered by such a license. Unfortunately, at this point it would probably be just a nuisance for litigious companies and it would be nearly impossible to prove anything anyhow.
The best defense against bogus software patents is simply to overwealmingly sweep the software market with superior, Free, commercially supported alternatives. No doubt some failing proprietary software companies will turn litigious in the process. But we must remember that the bogus lawsuits will end when the money dries up. Longer term, once all the cards are in the hands of Open Source driven companies, it will be a trivial matter to change patent policy.
And yes, I agree with Mitchell Baker that funding is essential. Love of the work is a large part of the reason for doing it, but love of success and fame and fortune are also a big part of it.
Funding is essential for OSS to succeed in the mainstream. However, I'm sure that many in the OSS community would gladly settle for "love of the work" + "a reasonable full-time salary." There's plenty of money out there for the taking. We just need to be smarter about how we go about getting at it. Take OpenOffice.org as example. Nearly every business in the world would benefit if OO.org was improved enough to become a serious alternative to MSO. Yet I don't see a flood of companies coming forth to support it, even with the high cost of MSO licenses! Sure, there's Sun.. but that's one company and they have direct commercial interests. Why is there not more momentum for a project this important that has already come so far? I don't know the details of what goes on behind the scenes, but something just doesn't add up. If I understand the OO.org website correctly, the team has not really pursued outside funding. I think they need to re-evaluate the advantages of bringing more full-time developers on board and then do some serious funding drives to make that possible.
Firefox/Thunderbird auto-update is currently worth crap. Just download the new version and use the silent install option: ie.) Firefox_Setup_1.0.2.exe -ms
The same thing works for Thunderbird. Usually I think it deletes the old Add/Remove options. (or at least one of them..) This is the most convenient quick-and-dirty way to update a bunch of machines in a small Windows domain.. put that command in everyone's login script the night before.
Patents and copyright need to be drastically revised to compensate _only_ the actual creative work.
IMO, that's exactly what we need to restore balance. With the exception of works done for hire, which are typically collective, companies should not be allowed to aquire intellectual monopoly rights from individuals or other companies. There's simply no need for this practice. Contract law is perfectly adequate. Publishers don't need to hold the rights to works to do their job. They are middlemen and it is entirely unfair for them to hold all the cards. (And with the direction technology is headed, they won't even be necessary in the future.. which as we all know is what the **AA are afraid of)
Another thing that should be outlawed are these patent rights holding companies that buy up rights for peanuts and then use them to leech off of healthy, productive companies. If a company goes bankrupt and is liquidated, the patents should either be automatically nullified or re-assigned to the individuals who actually produced the ideas. (Patent reform itself, of course, is another whole issue..)
I've done netboot installs with over 7000 seats, in 500+ geographic locations..
Wow.. I've certainly never done anything that large. My experience was more on a "workgroup" scale.. 20-40 boxes. So I don't doubt you ran into quite a bit more difficulty! Did any particular thing get in the way of smooth operation? What technologies were used?
The point of the removable storage with local apps is to mitigate the "but i cant work if the server is down" problem.
Hmm.. what about replicated servers to spread the load and reduce the effect of an outage? Then have some hot backups ready to swap in if needed..
network booting sucks big hairy mooseballs. trust me on this, it absolutely, positively sucks the big one.
I've done Linux network boot installations before and they work just fine once configured properly.
local boot into minimal OS, local apps on removable media, local data on removable media, remote apps on servers, and remote data on servers.
Replace "local" with "locally cached" and I'll agree with that statement. Who wants to have to go around updating hundreds of removable media devices every time the OS or certain apps change? Putting everything on the network is every administrator's dream. With OSS, it's even better because there's no seat-counting licensing hassles.
Indeed, the PC as a personal data island is dying. We'll see diskless workstations that network boot Linux/BSD/whatever and are used primarily to run a somewhat evolved Mozilla or Konqueror web browser supporting SVG, CSS3, XForms, etc. Most business apps will use rich-web, standards-compliant interfaces that feel no different than native clients -- except that they will be much better integrated than anything we've seen up to this point. Office suites will have been obsoleted by web-based document management systems, a component of said integrated business apps. Native apps will still be used as needed.. graphics, multimedia, etc. But they'll all be Open Source and loaded from the network. Every workstation in the office will thus have a complete and uniform collection of software available. (Unlike today, where employees must usually beg for a license of Photoshop, Illustrator, etc.)
At home, it'll be very similar.. every family member will have their own wireless terminal of sorts. All software and storage will be centralized to a server in the closet. Solid-state internal storage will allow for disconnected operation on trips, etc. but internet access will be so ubiquitous that you'll still be able to access your home web-based content portal.
We will see in the short .net CLR virtual clients.
Right idea.. wrong platform, wrong standards. We'll see diskless workstations that network boot Linux/BSD/whatever and are used primarily to run a somewhat evolved Mozilla or Konqueror web browser supporting SVG, CSS3, XForms, etc. Most business apps will use rich-web, standards-compliant interfaces that feel no different than native clients -- except that they will be much better integrated than anything we've seen up to this point. Office suites will have been obsoleted by web-based document management systems, a component of said integrated business apps. Native apps will still be used as needed.. graphics, multimedia, etc. But they'll all be Open Source and loaded from the network. Every workstation in the office will have a complete and uniform collection of software available. (Unlike today where employees must usually beg for a copy of Photoshop, Illustrator, etc.)
"Thin clients" will primarily not have local storage, aside from removable media; otherwise, they will be similar to current PCs, because it is necessary or cost-effective to do everything else per-client.
Precisely.. this is the part where Sun went wrong and Gates simply doesn't get. "Thin client" does not necessarily mean "200Mhz. processor and 32mb RAM running as a remote X terminal." That attempt indeed failed miserably as a mainstream solution. It's all about network storage and ideally network booting as well. (Though I would not be surprised to see solid-state local storage for caching and disconnected operation..)
Of course, this is all quite contrary to MS's plans for the PC Desktop, where an (expensive) OS platform is still relevant due to shunning industry web standards and pushing their own proprietary equivalents (XAML, Avalon, et.al.) I predict this will ultimately fail because commoditization won't have for it.
UNIX ceases to be UNIX when it doesn't feel like UNIX anymore. ... Webmin presents none of these things. It is therefore not UNIX. ... I am vehemently against even the mere dilution of anything UNIX.
/etc filesystem a "database." It's just not as granular as breaking large files down into many smaller ones. We're talking about the difference between whitespace and filesystem nodes for separating options. It's the same data. It's the same schema. It's just stored with more pointers.
Tools like Webmin can be installed and removed. They're optional. They're not part of the system. You can use them for quick and dirty changes and use your favorite shell and text editor for everything else. You can use them as training tools for new admins so they can get used to the configuration needs before they see what's really under the hood. So I'm not sure how you feel that the mere existance of tools which make Unix easier to admin for the majority somehow take away from its power when you use it. Look at it this way: We who are the old school Unix junkies will always be in the minority because most people simply aren't smart enough to do things the way we do. But would we rather them use Windows or use Unix with a candy-coated shell that we can easily peel away if we need to fix their machines?
I simply do not desire to wake up one day and find that someone has taken away everything I recognize as UNIX, and turned it into something which is only usable with a mindless point-and-drool interface.
You keep using words like "only usable" and "taken away" but nobody is doing this or even attempting to do this -- with the exception of MS who has done it already, but not to Unix.
I am particularly opposed to any changes that consist of a database for configuration data, even if that database does successfully masquarade as a directory tree.
You could easily call the
The world is currently cursed with the misuse of complicated databases, where they present no clear advantage over human-readable text.
No doubt there are many examples of databases gone wrong -- complication that adds no value. In the vast majority of cases, however, it's not that flat text would have been ideal. It's the fact that the database designers didn't really think about what they were doing and so the result became worse than just using flat text.
Because in order to use that database, I need interface software. And in order to use that interface software, I have to abandon the UNIX ways of doing things that I know and love.
By definition, passwd is a database. You can edit it by hand or you can use an interface like adduser. But you would certainly not argue that the person who wrote 'adduser' is out to destroy the Unix way of doing things.
Unless you've got actually got something substantially better (and believe me, it's been tried), please focus your efforts elsewhere.
Do you really honestly believe that there is no room for improvement in our "Unix" way of doing things and that it will exist forever? And therefore we shouldn't try anything new? I mean.. I'm sure there were folks who swore by hand wiring their computer's logic because it gave them more control than early micro-chips. But there's a certain over-arching concept in the whole world of computing that abstraction eventually makes technology more powerful. Lets say that a new generation of admin tools actually works at some point. Suppose it actually becomes much faster, safer, and powerful to configure your Unix system from a GUI. You can accept this and say to yourself, "well.. this does actually work.. and now I have more free time to try completely new things." Or you can say, "Heck with this.. I'm doing things the old way even if they are inferior" and eventually lose your job as everyone else moves on. I'm not claiming this is just around the corner, but it will
If everyone is off on some XML tangent, that must mean that everyone hates it.
Fortunately everyone hates XML for system admin and that's not what Elektra is proposing.
So what? They're different programs, written by different people, and doing different things in different ways. Of course they use different file formats for configuration.
Elektra is not an attempt to change the way applications are configured. It is only an attempt to create a standard for how that configuration is stored so that it is more easily parsed. It doesn't force any radical change upon anyone. And, in fact, it would be trivial for programs to support both config formats as a compile-time option. Elektra is little more than placing each config line in a separate file and using filesystem hierarchy in place of indents, curly brackets or other means of designating blocks.
Yes. This is why they're called *different distributions.*
Variance in filesystem locations is not what gives value to having different distributions.
Would someone PLEASE show me a video driver which requires an Apache plug-in?
The text you quoted was giving multiple examples, not saying anyone would try to combine these things.
And ISVs don't want their job made easier, or else they'd find themselves without one. Next.
I suspect this is the root of your distaste for making *nix OS'es easier to manage/configure and the basis for the irrational arguments you are making. Consider this.. there will always be jobs for ISVs because there aren't that many folks smart enough to do the job right. You still have to understand the options you're setting whether you're using vi or a GUI interface. A new generation of admin tools will simply enable you to a.) handle more customers or b.) do less work.
Shucks. You mean that HP/UX is different from Solaris?
The point is not that OS'es can be made to be the same or use the same options. The point is that if everyone used the same config storage schema, it would be much easier to learn and keep track of multiple platforms / distros. Again, I think you're reading into their proposal too much.
That's why they're self-documenting and human-readable.
And also messy as heck, thereby reducing readability.. If you put all the information necessary to properly document a config schema in the file itself, there'd be a page or two between each option in many cases. Typically, many details are left out, forcing the admin to reference multiple external documentation anyhow -- there goes the self-documenting part. And how many times have you configured most of the software at the end of the file and then had to go back later and dig through the commented out examples because you forgot the syntax? And then a new version of the software changes some options and crap.. now you have to merge your messy config file with a fresh version with up to date comments. (But by this time you've probably given up on the self-documenting part and just deleted all the comments anyhow to make your settings readable)
Backups, backups, backups. Has nobody yet learned the purpose of a proper *** backup regime? It's not just to recover from hardware failure, but to provide a window into the past.
Backups are one option.. so is CVS. But how many times do you change more than one option per file per backup cycle or CVS commit? I agree this is one of the weaker arguments for Elektra, but it would increase granularity of revision records slightly. With admin tools that employ optional XML meta-data (stored in separate files, not part of the config!) you could easily implement a full history of changes for every option in the hierarchy. You could even devise an easy way of doing rollbacks of any change or groups of changes at any point in history without having to hastle with manual merging.
Webmin, and all of its evil little friends, consists of a crutc
However, I will totally grant that a *major* innovation that will account for a large improvement in reliability, productivity, interoperability, and lower costs would catch a lot of eyes.
I don't see OO.org as an innovative project; I see it as a transitionary project. There's really not much innovation left within the current "word processing" paradigm. After all, it's nearly 30 years old now! So I see OO.org as a temporary free alternative for while the really innovative stuff is being worked on. I say transitionary because OO.org is a good way for people and businesses to begin migrating their documents out of proprietary formats into something future-proof. The future is web-driven document management systems where content and presentation are cleanly separated and all information is stored in a database instead of scattered throughout local and network filesystems in various formats. I'm not talking about the hack-job web groupware solutions available today where everything is done in a regular word processor and then uploaded to some intranet site. I'm talking about all work being done within a highly integrated, rich-web interface.
However, going back to my first point, how do you force that innovation along?
You put highly visionary people in charge of teams of highly motivated programmers who agree with the vision. (-: Have you noticed how fast the Blender3D project is moving along? Perfect example.. it's new, it's exciting, and everybody wants to help out. Not so many people are really that excited about doing OO.org development. It's not the cutting edge, it's pretty dull and boring work, much of it is re-inventing wheels. Yet OO.org is still very necessary at this time, so my thanks and appreciation to all those who are slugging away doing the hard work for the benefit of us all!
I believe people are probably already trying to do, but coming up with brilliant ideas is a little harder than sitting down and deciding to come up with brilliant ideas.
Software is a very evolutionary field. There really aren't any major breakthroughs.. just a bunch of baby steps of progress. Now, there are paradigm shifts, in which the combination of available technologies enables new approaches to old problems. (Such as my prediction that rich-web intranet apps will obsolete today's concept of word processing..) But it's really unfair to say that Open Source projects are "just copying" proprietary software because that proprietary software had a long history of copying other proprietary software and making small improvements along the way. It's really no different. (And it's why software patents are so bad for everyone. Even ol' Billy G admitted that back in the mid 90's.)
Is Elektra just XML metadata bolted onto an /etc like filesystem?
/ /sbin/nologin
/proc and /sys filesystems in Linux. When I talk about XML meta-data, I refer to the fact that, for example, at the root of "system/users" you might have a file "config.xml" which describes all the valid options and values in the "users" hierarchy. This would allow for really slick GUI admin tools, but would not compromise the ability to configure the system by hand if desired or necessary.
No. Elektra is a key-value based configuration scheme which uses the filesystem for storage, security, and hierarchy. http://elektra.sf.net
For example, instead of passwd and shadow, you might have this:
# system/users/nobody/uid: 99
# system/users/nobody/gid: 99
# system/users/nobody/gecos: Nobody
# system/users/nobody/home:
# system/users/nobody/shell:
# system/users/nobody/password: *
# system/users/nobody/passwdChangeBefore: 0
# system/users/nobody/passwdChangeAfter: 99999
# system/users/nobody/passwdWarnBefore: 7
# system/users/nobody/passwdDisableAfter:
# system/users/nobody/passwdDisabledSince:
# system/users/nobody/passwdReserved:
This is very similar to the modern
These are things that matter to the end user.
Correct.. external features, not internal technology, are what drive public acceptance. Firefox needs to continue to offer things that IE does not have. However, it should be noted that standards support can create public interest through superior webpages. How many people over the years have downloaded Flash because of the features it adds to their browsing experience or because certain fancy sites required it to display all content? (it's a pity Flash was not standards based.. like SVG + DOM + JS, which will replace it)
Implement something as powerful as Windows Forms (or it's Linux equivelent). It's the thing Microsoft fears the most
Mozilla already has XUL, but it's not a W3C web standard; it's a Mozilla standard. XUL will be replaced eventually by XForms, SVG, CSS3, and other true web standards. From all indication, Microsoft does not plan to implement XUL or the next generation of industry web standards. Why? Because they are creating their own proprietary, incompatible standards such as XAML and Avalon. These are features of Longhorn which borrow tons of ideas from XForms, SVG, XUL, etc. but will only work in Windows. Microsoft hates open web standards because they allow efficient competition. The more powerful web standards become, the less relevant desktop platforms become.
You're almost on the right track regarding the threat web technology poses to MS Office marketshare. However, the threat is not web browser equivalents to an office suite. And it won't entirely be the result of OpenOffice either. The real threat to MS Office is a shift in paradigm away from word processing altogether. In the future, most office workers will not create word processing documents in the sense of files saved to some network share. They'll enter lightly-formatted textual information into a web-based content management system and all layout will be taken care of automatically. After all, secretaries and businesspersons are not professional typesetters. Why should they have to worry about such things? And it should be easy to imagine how much easier revision control and document workflow will be with all information stored uniformly in a database rather than scattered in multiple file formats throughout filesystems and groupware messaging systems.
What about the other components of today's office suites? Well, spreadsheets are already dying out as real database technologies become cheaper, more powerful, and more accessible. Presentation tools are already highly competitive, with many 3rd party alternatives to PowerPoint. There's plenty of room here for new technologies and approaches. Furthermore, presentation documents are often one-time-use so there's much less need for strict backwards compatibility.
Leave /etc as it is. It works. It's done the right job now for coming on 30 years.
/etc is some sorta hideous XML jungle.. or a special daemon reliant mess like GConf that adds no value.
It works. It's far better than Windows registry. But it can be improved and this is what the Elektra project mentioned in the topic is all about. Unfortunately, it appears that nobody posting to this thread has actually read about the idea. (as usual.. skip the article and jump into a flamewar) Everyone just assumes the only alternative to
Elektra + optional XML meta-data now!
Why do you desire to take away my tools and replace them with the moral, conceptual, and visual equivilent to regedit? Is one coder's time worth the agony of the entire unix-using world?
/etc that actually makes sense.
I don't know how everyone got off on this silly XML tangent. Head over to http://elektra.sf.net to find a Unix-admin friendly alternative to
Elektra + optional XML meta-data now!
If you want to change /etc you are going to have to convince vi or even ed users like me. xml ain't gonna do it.
/proc or /sys.
I fully agree. Head on over to Elektra's website, http://elektra.sf.net, and ponder the alternative of breaking configuration down into a standard file hierarchy much like
And it would be trivial to re-combine everything into a single list for rapid text editing.. just traverse the tree. I'll bet an editor for this would be mere weekend project in Perl.
Elektra + optional XML meta-data now!
XML is the wrong approach, partly for the reason you mentioned. Head over to Elektra's website, http://elektra.sf.net and find out why their idea is so much better than both /etc and XML alternatives.
Now one thing you must consider, however, is that XML meta-data would be a good thing. It would allow you to edit your flat files in an Elektra hierarchy any way you wish, but it would also allow for rich, self-describing config trees easily managable with a rich GUI admin tools.
I vote for com.example.app.plist files
It's an improvement, but Elektra plus optional XML meta-data is much more powerful and flexible. Forget new APIs and use our trusty filesystems instead.. it makes perfect sense. Seriously.. head over to http://elektra.sf.net and read all about it! (:
OSS is about choises, and /etc really highlights this. People have different ideas on how apps should be configured
/etc. It makes security more granular. And most importantly, it opens the door for a new generation of GUI admin tools that will make Unix administration accessible to the masses of existing Windows admins who don't have time to re-learn everything they know. Of course, it'll also improve the lives of seasoned Unix admins as well. At least those who value their time..
OSS is about choices. But not all choices bring value to the community. As a long time Linux admin, I can tell you that peoples' different ideas on how apps should be configured does NOT bring any value whatsoever to Open Source. It does quite the opposite. We absolutely must find a compromise and bring sanity to the situation.
So far, Elektra is the best compromise. It doesn't require any new tools. It doesn't require any drastic changes in most software. It doesn't create any single points of failure. It retains the human readable and human editable nature of
Elektra + XML meta-data now! (:
to clear /etc/ you would create another one that would need programmers to comply to that?
/etc/ so that they're logically placed and findable?
/etc mess. It has very little to do with logical /etc organization. It has everything to do with trying to figure out what the options are, what the valid values are, and how to integrate the slew of packages necessary to make a working system for real-world needs. Yes, the real world needs standard, Open Source GUI admin tools.
Elektra-style configuration could easily be phased in over time. That's part of the beauty and simplicity of it.
wouldn't it be actually easier to get them to place stuff in
It wouldn't solve the problem -- which is that it takes too much time and effort to administer a system using today's
The Elektra design is on the right track. The only thing it is missing is optional XML meta-data that can describe the key-value hierarchy to a new generation of admin tools. Everything else is perfectly taken care of by the filesystem. Imagine if, instead of editing long, heavily commented config files, you could browse through a logical hierarchy of the options. Whenever you select an option, a side panel lists the valid values, describes their purpose, and gives usage examples. Upon edit, the admin tool validates the value entered and logs the change with a timedate stamp. If you want, you can add notes too.. these are stored in your home directory or optionally within the metadata as well. (though a different file)
Beyond configuring individual packages, switching a standardized config hierarchy would enable a new generation of intelligent, modular admin tools. As example, imagine if the software could automatically "wire up" all the tools needed for a complete mail or file server. You choose what packages you want and the admin tool looks up a default "recipe" for making them work together. Then all you have to do is configure the specifics for you installation. Sure beats endless HOWTO's for every combination of Linux distro, MTA, IMAP server, webmail, spam filter, virus filter, etc.
I've been administering Linux for 8 years now and this would absolutely be a dream come true.
A well commented config file with inline examples is even better.
.. Plus optional XML meta-data in the config hierarchy so we can make our lives easier with modern admin tools.
A GUI admin interface with all options, possible values, descriptions, and examples sourced from XML meta-data is even better.
Elektra now! (:
http://elektra.sf.net