I think "designed by monkeys" isn't a conclusion he gets from seeing it can't be parsed by Alien but rather its entire lack of semantics in the package files. The fact that it can't be parsed using Alien is not the relevant fact. The relevant fact is that it can't be parsed using anything!
I know XML is over hyped, but in this age you'd think people would have learned the value of using formats with explicit semantics. From Joey's post it would seem that the format of Autopackage's files is entirely lacking in this regard. As you say yourself, "Autopackage isn't a package format" (I think it would be clearer to say "Autopackage files lack a explicit package format").
That, in my opinion, is a little shortsighted. There will be a lot of things that people will eventually want to do with software distributed as Autopackage files and they won't be able since there are no semantics. Joey's case is just one initial example of this problem.
Wouldn't you think it better for Autopackage files to actually have a format with some semantics? Sure, you'd need to design a model that allows you to install those packages in any platform anticipating most things developers will want, which seems to be a bit more work than the simplistic "bah, its just a shell script that you run to install packages" approach, but I think it would work better in the long run.
Can you extract information of dependencies from Autopackage files (for example, to build a dependency tree)? Can you build a list of files that an Autopackage file will install? In that list, can you know the size of each file? Can you extract a list of relevant installation questions that users will be asked (for example, to automatically build a YaST module to config the package)? The specific answers to these questions are not relevant; what's relevant is to notice that should Autopackage become successful, people will want to do a lot of difficult to anticipate things with these files.
From the little I've read, your approach seems to be to add command line switches to the scripts that Autopackages are. Now I think about it, this is a good idea! If you add enough, people will be able to do all the things they might want to do from the packages just going the extra step of running them with the relevant switch and then parsing the output. But then, wouldn't it be better to have included just the output of these switches? This would require Autopackage to parse packages and install them on their own, but it would standarize everything.
Anyway, just my two cents. I'm really not familiar with Autopackage other than from the little I've read on its website and those I liked on my grandparent post.
I should have clarified what I meant when I said it is serves as a "development environment" that eventually becomes NLD/SLES. I didn't meant that it is used by developers for development work, but rather as the "testing" environment that allows Novell to test new technologies. Which is why I said Novell isn't likely to let its quality drop. That's what I meant.:)
When I say it isn't stable, I don't mean it in the "it crashes" sense but rather in the "its moving quickly" sense.
Before continuing to recommend Autopackage, you might want to read this post by Joey Hess from the Debian Project, where he calls it "Worst. Package. Format. Ever" and ponders if it was designed by monkeys (and he, the maintainer of Alien, does know a bit about package formats).
If you're interested, you might also want to read this post and the comments there.
The only reason I can think for them not to be entirely compatible is that SuSE Professional is released much more frequently than SLES. SLES 9 Sp2, for example, comes with a kernel based on 2.6.5 (with lots of fixes by Novell) and this will continue for the entire lifespan of SLES 9. This doesn't happen with SuSE Professional, which has an entirely different focus and is based on the latest available versions of all packages.
In order for them to be compatible, you'd need to drop the stability of SLES, which would be a stupid move, or stabilize SuSE Professional (rather than build it using the latest available versions of software), which would be a stupid move as well.
Providers of propietary software do certify it against specific distributions (and even versions). This is a process that takes time and money from them, so its a smarter move to certify against the stable distribution, not the constantly moving one, specially since their creator does not offer support for the latter.
And, anyway, you can legally run SLES for as long as you want without paying Novell (see this post in my weblog for more information)
So no, there are real reasons why they are not compatible and they are not your simplistic "they don't want them to be" ideas.
You can use SuSE Linux Enterpriser Server or Novell Linux Desktop, both of which are based in SuSE Professional (they are the "stable" version of SuSE Professional). Novell sells support for these two distributions.
Oh, and, btw, it is not uncommon to find Novell employees who use SuSE Professional instead of Novell Linux Desktop. Since SuSE Professional serves as a development environment that eventually becomes SLES/NLD, I do think Novell has reasons to care and make sure it doesn't suffer the fate you fear.
I think you mean NLD (Novell Linux Desktop) rather than NDL.
I'd also like to point out that NLD is strictly oriented for desktops; if you want to run SuSE on a server (with support from Novell), you should use SLES (SuSE Linux Enterprise Server).
Basically, SuSE Professional (and I suppose now OpenSUSE) is the development version of the distribution. It is changing fast, with new releases made very often (at least when compared with SLES and NLD). SLES and NLD, on the other hand, are much more stable. Novell recommends using SLES and NLD on corporate environments (instead of SuSE Professional).
Depending on the specific SuSE distribution (Novell Linux Desktop, SuSE Linux Enterprise Server, SuSE Professional) you'll find included components that are not open source such as the Java Runtime Environment, Acrobat Reader, Opera, Real Player and others.
To the best of my knowledge and making it clear that what I say here does not represent Novell and I am not a lawyer, I believe you are not legally allowed to redistribute SuSE (at least not if you keep copies).
As for the rest of what you say, I really don't know but my guess is that Open SuSE is all about allowing more community participation in the development process. For instance, public bugtracking (yes, I know about bugzilla.novell.com), public development mailing lists, etc..
A lot of people have put a lot of time volunteering into projects with the goal of creating software than anyone can use, redistribute and modify (and that even your own company has used in order to build better products). While this might not seem a worthy goal for you, it has inspired *many*. Don't you have ethical issues working in a company that has the explicit goal of destroying these public goods (by means such as software patents, running misleading marketing and extending standards to make it difficult for this software to interoperate)?
I was about to suggest you use Zenworks right before I read you mention it in your question. I would advise you to give it a try: it was designed precissely to provide the functionality you seem to be looking for.
Not only it lets you automatically update software (other posts have pointed out that you can trivially do this in Debian-based distributions with a cron job) but it will also help you easily define default settings for each application and group of users.
OpenBSD and NetBSD are forks of the original BSD because they have taken the BSD code and turned it into their own divergent systems, both based on the same base but heading in different directions.
Correction: OpenBSD is a fork of NetBSD, not of original BSD. I suppose since NetBSD is a fork of 386BSD, you could claim that OpenBSD is a fork of 386BSD anyway, but you shouldn't claim that they have the same base. NetBSD is (was, at the time of the fork, when Theo was kicked out of NetBSD's core) OpenBSD's base.
I feel the most productive when using the tools I've grown to depend on.
For text editing, I really can't drop Vim. I don't like its architecture. While I really enjoy programming in Lisp and I find Emacs architecture much better than Vim's, using all of Vim's advanced features allows me to write (more often than not that means code) very fast.
Also, I really can't use any window manager other than Ion. Most of the time I only use one big window taking all the screen space and use the tabs (well, the keyboard, really) to switch to other windows. This allows the current window to take (almost) all the available screen space and allows me to focus on what I'm doing.
Finally, my life would be very different without GNU Screen. If your work involves using a console (for whatever reason), I strongly advise you to take some time to learn how to use it.
I'll throw in Mutt and Bash as a bonus. Can't live without them.
Oh, in case you're wondering, the platform would be any Unix where those run (usually Debian but I like other distributions and BSDs as well).
Microsoft's MS-Linux would quickly become the dominant Linux and the company would begin to profit from all the open-source development work that would go into Linux. Once the developers saw that happen they'd stop working on Linux and it would die.
This is the most absurd assumption I've heard today. Many companies currently benefit from the work of free software contributors (whether they are paid to work on free software or they are just volunteers). Sun, IBM, Apple and Novell just to name four.
I don't think any important developers would stop working on Linux just because Microsoft would also benefit. The most common reasons why developers work on free software have nothing to do with hurting Microsoft but rather with creating useful software.
Man, v is used for one of the most useful commands, visual selection! It allows you to select blocks (using any of the navigation commands such as/, h, j, k, l, f, F, w, etc.) and then apply a command (such as x, y, ~, etc.) to them. Very useful. I recommend you check it out.
At least you said 'Q' instead of 'q'; I really couldn't live without macros.:)
It is surprising that, even though we are constantly finding local security vulnerabilities in Linux, some people still claim it is a relatively secure operating system.
These are exploits in the most basic portions, against which a sysadmin can do nothing other than keep on patching things. It's not like you could have tunned this system to make it very secure, no, no matter how carefully you (or your distributor) set it, bang, a local exploit seems to be found every month or two.
I'm seriously considering going back to BSD (maybe Debian GNU/NetBSD?), which seems to have a much much much better security track.
Hmm, if these numbers are to be trusted, the infections are 10.5 generations old, on average.
Interestingly, these numbers add to 124k, much more than the reported 39k number of pages reported by merely searching for "NeverEverNoSanity". This would imply that many of the defaced pages contain messages for different generations. Weird.
It would be interesting if the defaced pages included the URL of the parent, the one that the worm used to infect the server from which it infected the current one.
Is Google filtering out results for this search, or is it simply that both Microsoft's search services update their indexes much faster than Google does?
You know, this is precissely how OpenBSD was born. Theo de Raadt was contributing to NetBSD until the NetBSD core decided to remove his write privileges from its sources. Theo, upset, decided to fork and start OpenBSD.
Originally, it had nothing to do with security, but rather with "openness" (from Theo's point of view, after he was kicked out). I suppose it would be called SecureBSD had security been the reason Theo started working on it.
What a useful idea, form autocomplete based on popular search terms implemented entirely in JavaScript and showing you the number of results your search would produce. Makes you wonder why nobody had implemented this feature before.
Hmm, the number of results it reports that each search would produce seem to be slightly less than the actual number of results they do. I suppose they need to resync their databases.
Slashdot Mirror
I think "designed by monkeys" isn't a conclusion he gets from seeing it can't be parsed by Alien but rather its entire lack of semantics in the package files. The fact that it can't be parsed using Alien is not the relevant fact. The relevant fact is that it can't be parsed using anything!
I know XML is over hyped, but in this age you'd think people would have learned the value of using formats with explicit semantics. From Joey's post it would seem that the format of Autopackage's files is entirely lacking in this regard. As you say yourself, "Autopackage isn't a package format" (I think it would be clearer to say "Autopackage files lack a explicit package format").
That, in my opinion, is a little shortsighted. There will be a lot of things that people will eventually want to do with software distributed as Autopackage files and they won't be able since there are no semantics. Joey's case is just one initial example of this problem.
Wouldn't you think it better for Autopackage files to actually have a format with some semantics? Sure, you'd need to design a model that allows you to install those packages in any platform anticipating most things developers will want, which seems to be a bit more work than the simplistic "bah, its just a shell script that you run to install packages" approach, but I think it would work better in the long run.
Can you extract information of dependencies from Autopackage files (for example, to build a dependency tree)? Can you build a list of files that an Autopackage file will install? In that list, can you know the size of each file? Can you extract a list of relevant installation questions that users will be asked (for example, to automatically build a YaST module to config the package)? The specific answers to these questions are not relevant; what's relevant is to notice that should Autopackage become successful, people will want to do a lot of difficult to anticipate things with these files.
From the little I've read, your approach seems to be to add command line switches to the scripts that Autopackages are. Now I think about it, this is a good idea! If you add enough, people will be able to do all the things they might want to do from the packages just going the extra step of running them with the relevant switch and then parsing the output. But then, wouldn't it be better to have included just the output of these switches? This would require Autopackage to parse packages and install them on their own, but it would standarize everything.
Anyway, just my two cents. I'm really not familiar with Autopackage other than from the little I've read on its website and those I liked on my grandparent post.
Erm, that link is http://azul.freaks-unidos.net/posts/Questions%20Ab out%20SuSE%20Licensing.html, of course.
I should have clarified what I meant when I said it is serves as a "development environment" that eventually becomes NLD/SLES. I didn't meant that it is used by developers for development work, but rather as the "testing" environment that allows Novell to test new technologies. Which is why I said Novell isn't likely to let its quality drop. That's what I meant. :)
When I say it isn't stable, I don't mean it in the "it crashes" sense but rather in the "its moving quickly" sense.
Before continuing to recommend Autopackage, you might want to read this post by Joey Hess from the Debian Project, where he calls it "Worst. Package. Format. Ever" and ponders if it was designed by monkeys (and he, the maintainer of Alien, does know a bit about package formats).
If you're interested, you might also want to read this post and the comments there.
The only reason I can think for them not to be entirely compatible is that SuSE Professional is released much more frequently than SLES. SLES 9 Sp2, for example, comes with a kernel based on 2.6.5 (with lots of fixes by Novell) and this will continue for the entire lifespan of SLES 9. This doesn't happen with SuSE Professional, which has an entirely different focus and is based on the latest available versions of all packages.
In order for them to be compatible, you'd need to drop the stability of SLES, which would be a stupid move, or stabilize SuSE Professional (rather than build it using the latest available versions of software), which would be a stupid move as well.
Providers of propietary software do certify it against specific distributions (and even versions). This is a process that takes time and money from them, so its a smarter move to certify against the stable distribution, not the constantly moving one, specially since their creator does not offer support for the latter.
And, anyway, you can legally run SLES for as long as you want without paying Novell (see this post in my weblog for more information)
So no, there are real reasons why they are not compatible and they are not your simplistic "they don't want them to be" ideas.
You can use SuSE Linux Enterpriser Server or Novell Linux Desktop, both of which are based in SuSE Professional (they are the "stable" version of SuSE Professional). Novell sells support for these two distributions.
Oh, and, btw, it is not uncommon to find Novell employees who use SuSE Professional instead of Novell Linux Desktop. Since SuSE Professional serves as a development environment that eventually becomes SLES/NLD, I do think Novell has reasons to care and make sure it doesn't suffer the fate you fear.
I think you mean NLD (Novell Linux Desktop) rather than NDL.
I'd also like to point out that NLD is strictly oriented for desktops; if you want to run SuSE on a server (with support from Novell), you should use SLES (SuSE Linux Enterprise Server).
Basically, SuSE Professional (and I suppose now OpenSUSE) is the development version of the distribution. It is changing fast, with new releases made very often (at least when compared with SLES and NLD). SLES and NLD, on the other hand, are much more stable. Novell recommends using SLES and NLD on corporate environments (instead of SuSE Professional).
Depending on the specific SuSE distribution (Novell Linux Desktop, SuSE Linux Enterprise Server, SuSE Professional) you'll find included components that are not open source such as the Java Runtime Environment, Acrobat Reader, Opera, Real Player and others.
To the best of my knowledge and making it clear that what I say here does not represent Novell and I am not a lawyer, I believe you are not legally allowed to redistribute SuSE (at least not if you keep copies).
You can read about this in a post I made in my weblog a week ago.
As for the rest of what you say, I really don't know but my guess is that Open SuSE is all about allowing more community participation in the development process. For instance, public bugtracking (yes, I know about bugzilla.novell.com), public development mailing lists, etc..
A lot of people have put a lot of time volunteering into projects with the goal of creating software than anyone can use, redistribute and modify (and that even your own company has used in order to build better products). While this might not seem a worthy goal for you, it has inspired *many*. Don't you have ethical issues working in a company that has the explicit goal of destroying these public goods (by means such as software patents, running misleading marketing and extending standards to make it difficult for this software to interoperate)?
He never suggests the creation of another list: his point is that someone might create one but it would be pointless.
You call that news for nerds, stuff that matters?!
Then again, if this move is inspired by DRM, I could see your point. It used to be *your* computer, now its only a computer.
I was about to suggest you use Zenworks right before I read you mention it in your question. I would advise you to give it a try: it was designed precissely to provide the functionality you seem to be looking for.
Not only it lets you automatically update software (other posts have pointed out that you can trivially do this in Debian-based distributions with a cron job) but it will also help you easily define default settings for each application and group of users.
Disclaimer: I work at Novell.
Correction: OpenBSD is a fork of NetBSD, not of original BSD. I suppose since NetBSD is a fork of 386BSD, you could claim that OpenBSD is a fork of 386BSD anyway, but you shouldn't claim that they have the same base. NetBSD is (was, at the time of the fork, when Theo was kicked out of NetBSD's core) OpenBSD's base.
Also, I really can't use any window manager other than Ion. Most of the time I only use one big window taking all the screen space and use the tabs (well, the keyboard, really) to switch to other windows. This allows the current window to take (almost) all the available screen space and allows me to focus on what I'm doing.
Finally, my life would be very different without GNU Screen. If your work involves using a console (for whatever reason), I strongly advise you to take some time to learn how to use it.
I'll throw in Mutt and Bash as a bonus. Can't live without them.
Oh, in case you're wondering, the platform would be any Unix where those run (usually Debian but I like other distributions and BSDs as well).
Novell is using OOo almost exclusively these days...
Stuff that matters, indeed.
I don't think any important developers would stop working on Linux just because Microsoft would also benefit. The most common reasons why developers work on free software have nothing to do with hurting Microsoft but rather with creating useful software.
At least you said 'Q' instead of 'q'; I really couldn't live without macros. :)
No particular reason other than me liking Debian a lot, I suppose. But you're right, maybe I should run the real NetBSD.
These are exploits in the most basic portions, against which a sysadmin can do nothing other than keep on patching things. It's not like you could have tunned this system to make it very secure, no, no matter how carefully you (or your distributor) set it, bang, a local exploit seems to be found every month or two.
I'm seriously considering going back to BSD (maybe Debian GNU/NetBSD?), which seems to have a much much much better security track.
I sure hope you broke your essay in more paragraphs than your article, though.
Here, you can have some enters:
ENTER ENTER ENTER ENTER ENTER.
Searching for "neverevernosanity webworm generation X" on MSN Beta Search yields the following number of results for each value of X:
Hmm, if these numbers are to be trusted, the infections are 10.5 generations old, on average.
Interestingly, these numbers add to 124k, much more than the reported 39k number of pages reported by merely searching for "NeverEverNoSanity". This would imply that many of the defaced pages contain messages for different generations. Weird.
It would be interesting if the defaced pages included the URL of the parent, the one that the worm used to infect the server from which it infected the current one.
Is Google filtering out results for this search, or is it simply that both Microsoft's search services update their indexes much faster than Google does?
Weird.
You know, this is precissely how OpenBSD was born. Theo de Raadt was contributing to NetBSD until the NetBSD core decided to remove his write privileges from its sources. Theo, upset, decided to fork and start OpenBSD.
Originally, it had nothing to do with security, but rather with "openness" (from Theo's point of view, after he was kicked out). I suppose it would be called SecureBSD had security been the reason Theo started working on it.
You can find out more about this straight from the horse's mouth.
So, I suppose, forking established projects due to disagreements such as these is nothing new for the OpenBSD people.
What a useful idea, form autocomplete based on popular search terms implemented entirely in JavaScript and showing you the number of results your search would produce. Makes you wonder why nobody had implemented this feature before.
Hmm, the number of results it reports that each search would produce seem to be slightly less than the actual number of results they do. I suppose they need to resync their databases.