A/UX booted in about 90 seconds on a Mac Quadra 950. 33MHz 68040. As far as I can tell, it had most of the functionality of Mac OS X today - albeit without the slick visual effects and more modern GUI.
In other words, albeit without any of the reasons anyone might buy a Mac today.
You'd probably wind up replacing two governments at war with a bunch of guerilla fighters of varying levels of sophistication and organisation.
I would point out that "a bunch of guerilla fighters" like I just described isn't a million miles away from the current situation in Iraq as I understand it and look how well that's turning out.
Could someone explain how exactly a rootkit detector can guarantee to be even vaguely reliable on a rooted system? By definition, once rooted you can't trust any of the underlying libraries or even the kernel to do as you expect.
My understanding was the best you can do is boot from CD and then examine the hard disk which actually has the OS installed.
At the time, a simplistic way to distinguish between "reasonably big iron which was bought by someone who obviously had money to burn" and "ordinary desktop PC" without doing all sorts of strange tests would be simply to count the number of processors. You'll have one in most PCs, 2 in a high powered workstation. Any more than that, it's pretty much guaranteed to be a server class machine.
From a marketing perspective, it's common practise to carve a market up into chunks according to "how much each chunk is prepared to pay for a product", and pitch different versions of essentially the same product (perhaps with the odd feature added or removed) to each chunk. License according to processors, and you force the part of the market which is prepared to buy a very expensive system (and thus must have a fair bit of cash) to buy the more expensive OS to go with it. Similar reasoning is why there's so many different versions of Vista.
There's no real difference between that and an OS which aggressively caches data and has an enormous amount of RAM in which to do it, except my suggestion can automatically keep frequently used files in RAM.
As an aside, Acorn's RISC OS (which was never a big hit outside of UK schools) had this functionality built into the operating system in 1988. Yes, you read that right - almost 20 years ago. Never ceases to amaze me how many things get reinvented.
In all fairness, we are talking about the middle east here. A part of the world which has been at war on and off for longer than many of the countries there have existed.
Various governments both within the middle east and outside it have been trying to calm the situation down there and so far they've had a 0% success rate. Were it not for the violence spilling into the US in the 9/11 attacks.
We've already got that. Most modern OS's (IIRC even Windows to a certain extent) aggressively cache as much as they can in RAM so as to avoid hitting the disk.
However, the amount of data that's stored on the disk means that the RAM cache is inevitably a lot smaller than it really needs to be. A faster disk would, as you say, go some way to alleviating this.
"Multicore" is essentially SMP (multiprocessor) but all on one physical chip rather than several. Windows has supported that ever since the days of NT 4, but its architecture is more suited to 2 or 4 cores rather than 16 or 24.
It's not/. users that read "parallelize" as "paralyze" that's the problem. It's when Microsoft's own staff do and they wind up writing an OS which does exactly that, that's the problem.
Punishment in general isn't a deterrent. If it was, there would be hardly anyone committing murder in the US states which still have the death penalty.
It's often thought that the best deterrent is fear of getting caught. Put police officers on the streets rather than behind desks.
I'm not an aircraft designer, so I know bugger all about what I'm talking. (Why I think I'm therefore qualified to expound at length on the subject on/. is a separate discussion for another day).
If you're talking about completely re-engineering the fuselage with a bloody great bulkhead between cockpit and cabin, fitting another door on the outside and getting all that past the various safety authorities (either retrofitting an existing plane or building into the design of a new one), adding "fit a modern ILS" doesn't sound so prohibitive. Particularly if you design it into new planes rather than try retrofitting.
Further to that, prior to 9/11, 99% of hijackings resulted in one of two things:
1. Hijacker is arrested the moment they get off the plane and spends a nice long time in prison. 2. Hijacker is shot the moment they get off the plane and spends a nice long time dead.
Yes, but it's a lot easier to declare war on a concept that (more or less by definition) you can't beat by shooting at than it is to solve world hunger and abolish inequality over the entire planet.
Or, to put it another way (for those who still think the US is doing well in Iraq): Think of terrorism like a vicious, unpredictable animal that wants to attack you. That's easy enough. But there's a twist: it gets stronger every time you shoot at it, bomb it or do anything violent towards it. Why are you still shooting at it?
Silly question, but I've got a serious anecdote. Yes, this really happened.
Back when I was in school (this is circa 1996, we were using HP LaserJet 4L's), a few chaps discovered that they could run the same sheet of paper through a printer more than once.
They came up with the brilliant idea of printing a picture over the whole page, then running the same sheet of paper through the printer, only this time print out some white text on a white background over it. They expected a result of white text overlaid on the dark picture "because it'll appear like that with the white ink, won't it?".
I wasn't aware that Gentoo started dropping older packages though. I've never run in to that.
Well, it does. You can prove it for yourself if you like, with the following steps:
Install a Gentoo system.
Leave it for two years or so. You can do periodic emerge --sync ; emerge world if you like, I don't think it makes much difference.
Carry out a major package installation/upgrade. Something like a major PHP version upgrade is good.
If you didn't do the emerge --sync before the major installation, discover that a number of the URLs stored in the various packages you need to install are now defunct. Swear, do an emerge --sync and try again.
Marvel at all the things which are going to have to be upgraded.
Get halfway through the upgrades, discover something's broken as a result of them. Swear. Search the forums, find out that it was decided to completely re-work how Gentoo does something about 8 months previously, and all support for the old mechanism has now been dropped.
Yes, if you do need a package that is years or majorly versioned out of date - it's a good idea to have a copy of it if you ever run into a problem. Most Gentoo systems keep this on hand by default unless it's been customized to not to.
Either I misunderstand what you say or you are flat-out wrong. You can automatically keep a copy of a package as you install it, and you can build one yourself later with quickpkg, but I haven't seen that behaviour as a default... ever.
hopefully the previous sysadmin was semi-competent and kept his own package repository for customizing ebuilds, package management, cross compiling, and just as plain common sense so again you're not hosed if you don't actually have a copy of the relevant software around.
The phrase "cross-compiling" does not make any sense in the context you use it. I understand it to mean "compile a package for one combination of OS/hardware on another OS/hardware combination".
As regards the previous sysadmin: they're not here to defend themselves. All I shall say is that there was no private package repository when I came to the company, and most of the servers were too far customised to benefit from one.
I know and work with a guy that's got over 100 systems, with secure distcc compilation...
And from the rest of your description, it seems to me that your guy planned the whole lot out from scratch taking Gentoo's inherent bit rot into account. The sheer unholy mess you will find if that isn't done is something you really have to see to believe, and when it gets to that point it's probably easier to rebuild the server from scratch.
Just to put it into context: one of the older servers recently decided that it had two versions of all the base utilities (including things like/bin/ls and/bin/bash) installed and decided to delete one. Because it was set up so long ago without all the things you discuss, it's not clear why or how it got this confused. I can tell you, however, that it's quite surreal trying to use a Linux system without/bin/bash or/bin/ls. I'm sure it would have been repairable, but when it's a 10 hour job to repair it or a 4 hour job to install Debian, migrate all the data across and go to bed knowing that this is much less likely to ever happen again, Debian starts to look rather attractive.
I thank the Flying Spaghetti Monster that happened on a separate test network.
In my current job, I inherited a whole bunch of servers running Gentoo.
Not wishing to rock the boat, and not having a problem with gentoo per se, initially I maintained the status quo.
A few weeks ago, I made a decision. Future server rollouts will be Debian, Gentoo will slowly be discontinued. The reason is nothing to do with installation - I've got enough experience with it that I could install Gentoo in my sleep with my hands tied behind my back.
The problem is one of maintenance. With Debian or RedHat or Mandriva or almost any other Linux distribution, there's a specific version. A line in the sand, if you will, which states "this is what version we're dealing with".
Gentoo gets rid of all that, in favour of individual packages being marked stable/masked ("unstable")/hard masked ("very unstable, will break things, you have been warned"). In theory, you never have to do a major version upgrade of a Gentoo system. You just install everything that's marked stable that you want, if you need something specific that hasn't been marked stable you unmask it. A bit like running Debian Stable with the odd package from the testing branch.
This sounds great, until I now point out the problem.... Gentoo suffers from bit rot. Before you mark me down as a troll, let me explain. Packages still turnover as they age. Eventually, packages are marked obsolete - ie. dropped from portage altogether - and unless you've already taken account of this possibility, once that happens it's a bugger to reinstall them. And once a package is dropped because it's obsolete, sooner or later other packages won't take account of the older versions quirks and version dependencies become at least partly down to luck. Good luck rebuilding a system which has failed with the exact same versions of all the packages it had on there - if it's not been updated in a while and you haven't accounted for such a possibility, the task is to all practical purposes impossible. Combine this with package QA which frankly is nothing like that of Debian - "Stable" generally means "It doesn't cause anyones individual PC to keel over horribly", not "It plays nicely with everything else in the network like it's suppsoed to" - and you've got a recipe for long drawn-out pain if you're trying to run Gentoo on anything more than a few systems.
The only solutions that I've found are:
Take account of this, download and compile everything you're ever likely to need on day 1, then if your needs ever change, repeat the entirety of this with a new server and migrate data across. Never upgrade individual packages, nor install anything new after day 1. Not really an option unless you really like missing out on security updates.
Update your system with emerge --sync ; emerge world regularly. "Regularly" probably means at least once a week. Be warned that package upgrades can and do occasionally break things - sometimes you get told about this, generally shortly after the new package is installed and sometimes you don't and you find out the hard way. Only really practical if you've got a complete replication of every damn system to test things on first, and even then it soon falls apart once you've got any serious number of servers.
Note that I've omitted "keep a copy of every package you install" or "make a note of the version of every package you install". These are effectively useless because ebuilds frequently use the packages sourceforge site to download the code from, and if the package moves or the version that you have in your (old) copy of the portage database is removed from sourceforge, you can't install that package and you've got to do an emerge --sync to get an updated ebuild (and an updated everything else in the process). It's not like any other distribution where the mirrors keep a copy of every package so it doesn't much matter if the upstream server on which the project is hosted breaks somehow. Unless you keep every package from day 1 complete with all its dep
That methodolgy won't scale terribly well if you ship more than a handful of CDs. And the risks are huge - not only are you likely to wind up pissing any customers whose CD does get taken by customs, you're also in contempt of court as regards the UK judgement and thus in even hotter legal water.
What a good idea. It's such a good idea, in fact, that it already exists. There's nothing in law to stop me from purchasing a product from the USA and having it shipped to the UK, and I'm liable for any taxes which it attracts on the way in.
But it's not the taxes that concern Adobe, the BPI or whoever. The taxes go to the government. What concerns the BPI is that the organisation I'm buying the product from makes it trivially easy for me to buy the product for substantially less money - much of the money I save would otherwise have gone to them. This is more commonly known as "grey market" goods.
The general solution is to make life difficult for companies which choose to sell me the product for substantially less money. Let's pretend I'm the company that's dealing in grey market goods - various techniques exist to make my life difficult:
Ensure that my orders from the manufacturer/distributor are always fulfilled last. Virtually impossible for me to prove that this is happening, and even if I can I also need to prove that it's as a direct result of my selling goods on the grey market. I'll also be hit the hardest if there's a shortage of anything, such as the latest games console.
Trademark infringement. Levi Strauss has a trademark on the name Levi, and technically anyone who uses their name without their permission is guilty of infringement.
I very much doubt every little shop selling Levi jeans up and down the country has a license to use Levi's trademark - but that doesn't bother Levi Strauss as long as the shop is selling UK-sourced goods for UK prices. As soon as I come on the scene though, selling US-sourced jeans at US prices to UK customers, I'm sued for trademark infringement. I can continue to sell Levi jeans at a knockdown price - but I can't use the name Levi or their logo anywhere in my advertising material. Good luck selling Levi jeans when the most you can do is advertise them as "Famous Brand!!oneone11!" - you'll look like a cheap, nasty ripoff shop selling fake goods which nobody who would generally buy Levis will go within a hundred miles of. In short, exactly what Levis want.
"Voluntary" agreements. I voluntarily enter into an agreement not to sell grey-market goods, on the understanding that if I do I won't suffer either of the above. Of course, suddenly you're into contract law, so if I say "screw this agreement, I'm going to do it anyway", the industry which had me sign the agreement can take me to court.
CDs were developed in the late 1970's/early 1980's. The Internet as we know it didn't exist (no DNS or WWW), international phone calls were damn expensive and shipping costs to get a single CD from halfway across the globe were insane compared with today.
The idea that there might be a booming trade in companies selling CDs individually to private customers, shipping each disc individually from Hong Kong to the UK, and doing so substantially cheaper than UK record shops could sell CDs for (even after including postage costs) would have been laughable.
What assets does a company like that need? A computer system to handle orders, an office to site it, a warehouse for stock (nether of which are likely to be owned by the company in the first place) and that's about it AFAICT.
Slashdot Mirror
Sounds exactly like every mainstream virus scanner in history.
A/UX booted in about 90 seconds on a Mac Quadra 950. 33MHz 68040. As far as I can tell, it had most of the functionality of Mac OS X today - albeit without the slick visual effects and more modern GUI.
In other words, albeit without any of the reasons anyone might buy a Mac today.
You'd probably wind up replacing two governments at war with a bunch of guerilla fighters of varying levels of sophistication and organisation.
I would point out that "a bunch of guerilla fighters" like I just described isn't a million miles away from the current situation in Iraq as I understand it and look how well that's turning out.
Could someone explain how exactly a rootkit detector can guarantee to be even vaguely reliable on a rooted system? By definition, once rooted you can't trust any of the underlying libraries or even the kernel to do as you expect.
My understanding was the best you can do is boot from CD and then examine the hard disk which actually has the OS installed.
It made a lot of sense at the time though.
At the time, a simplistic way to distinguish between "reasonably big iron which was bought by someone who obviously had money to burn" and "ordinary desktop PC" without doing all sorts of strange tests would be simply to count the number of processors. You'll have one in most PCs, 2 in a high powered workstation. Any more than that, it's pretty much guaranteed to be a server class machine.
From a marketing perspective, it's common practise to carve a market up into chunks according to "how much each chunk is prepared to pay for a product", and pitch different versions of essentially the same product (perhaps with the odd feature added or removed) to each chunk. License according to processors, and you force the part of the market which is prepared to buy a very expensive system (and thus must have a fair bit of cash) to buy the more expensive OS to go with it. Similar reasoning is why there's so many different versions of Vista.
There's no real difference between that and an OS which aggressively caches data and has an enormous amount of RAM in which to do it, except my suggestion can automatically keep frequently used files in RAM.
As an aside, Acorn's RISC OS (which was never a big hit outside of UK schools) had this functionality built into the operating system in 1988. Yes, you read that right - almost 20 years ago. Never ceases to amaze me how many things get reinvented.
In all fairness, we are talking about the middle east here. A part of the world which has been at war on and off for longer than many of the countries there have existed.
Various governments both within the middle east and outside it have been trying to calm the situation down there and so far they've had a 0% success rate. Were it not for the violence spilling into the US in the 9/11 attacks.
One suggestion that's been expounded is to introduce Marmite to the middle east. Myself, I think it smacks slightly of desperation, but hey....
They did win easily. Saddam lasted a few weeks.
But they're now discovering that one of the hardest jobs an army can be tasked with is to keep the peace.
What about a massive RAM drive?
We've already got that. Most modern OS's (IIRC even Windows to a certain extent) aggressively cache as much as they can in RAM so as to avoid hitting the disk.
However, the amount of data that's stored on the disk means that the RAM cache is inevitably a lot smaller than it really needs to be. A faster disk would, as you say, go some way to alleviating this.
Say what?
"Multicore" is essentially SMP (multiprocessor) but all on one physical chip rather than several. Windows has supported that ever since the days of NT 4, but its architecture is more suited to 2 or 4 cores rather than 16 or 24.
Your comment is only valid for Windows '9x.
It's not /. users that read "parallelize" as "paralyze" that's the problem. It's when Microsoft's own staff do and they wind up writing an OS which does exactly that, that's the problem.
but when a program crashes in windows it takes the whole system down.
Not true, unless you're still using Windows '9x. Rogue drivers are another matter altogether, but that's the same issue in Linux.
Having said that, I have seen userland code cause BSODs in Windows. But not in a very long time.
I've no idea why you've been modded "Funny". IIRC, NT4 was licensed in exactly this way.
Punishment in general isn't a deterrent. If it was, there would be hardly anyone committing murder in the US states which still have the death penalty.
It's often thought that the best deterrent is fear of getting caught. Put police officers on the streets rather than behind desks.
I'm not an aircraft designer, so I know bugger all about what I'm talking. (Why I think I'm therefore qualified to expound at length on the subject on /. is a separate discussion for another day).
If you're talking about completely re-engineering the fuselage with a bloody great bulkhead between cockpit and cabin, fitting another door on the outside and getting all that past the various safety authorities (either retrofitting an existing plane or building into the design of a new one), adding "fit a modern ILS" doesn't sound so prohibitive. Particularly if you design it into new planes rather than try retrofitting.
Further to that, prior to 9/11, 99% of hijackings resulted in one of two things:
1. Hijacker is arrested the moment they get off the plane and spends a nice long time in prison.
2. Hijacker is shot the moment they get off the plane and spends a nice long time dead.
Yes, but it's a lot easier to declare war on a concept that (more or less by definition) you can't beat by shooting at than it is to solve world hunger and abolish inequality over the entire planet.
Or, to put it another way (for those who still think the US is doing well in Iraq): Think of terrorism like a vicious, unpredictable animal that wants to attack you. That's easy enough. But there's a twist: it gets stronger every time you shoot at it, bomb it or do anything violent towards it. Why are you still shooting at it?
Silly question, but I've got a serious anecdote. Yes, this really happened.
Back when I was in school (this is circa 1996, we were using HP LaserJet 4L's), a few chaps discovered that they could run the same sheet of paper through a printer more than once.
They came up with the brilliant idea of printing a picture over the whole page, then running the same sheet of paper through the printer, only this time print out some white text on a white background over it. They expected a result of white text overlaid on the dark picture "because it'll appear like that with the white ink, won't it?".
Well, it does. You can prove it for yourself if you like, with the following steps:
Yes, if you do need a package that is years or majorly versioned out of date - it's a good idea to have a copy of it if you ever run into a problem. Most Gentoo systems keep this on hand by default unless it's been customized to not to.
Either I misunderstand what you say or you are flat-out wrong. You can automatically keep a copy of a package as you install it, and you can build one yourself later with quickpkg, but I haven't seen that behaviour as a default... ever.
hopefully the previous sysadmin was semi-competent and kept his own package repository for customizing ebuilds, package management, cross compiling, and just as plain common sense so again you're not hosed if you don't actually have a copy of the relevant software around.
The phrase "cross-compiling" does not make any sense in the context you use it. I understand it to mean "compile a package for one combination of OS/hardware on another OS/hardware combination".
As regards the previous sysadmin: they're not here to defend themselves. All I shall say is that there was no private package repository when I came to the company, and most of the servers were too far customised to benefit from one.
I know and work with a guy that's got over 100 systems, with secure distcc compilation...
And from the rest of your description, it seems to me that your guy planned the whole lot out from scratch taking Gentoo's inherent bit rot into account. The sheer unholy mess you will find if that isn't done is something you really have to see to believe, and when it gets to that point it's probably easier to rebuild the server from scratch.
Just to put it into context: one of the older servers recently decided that it had two versions of all the base utilities (including things like
I thank the Flying Spaghetti Monster that happened on a separate test network.
Not wishing to rock the boat, and not having a problem with gentoo per se, initially I maintained the status quo.
A few weeks ago, I made a decision. Future server rollouts will be Debian, Gentoo will slowly be discontinued. The reason is nothing to do with installation - I've got enough experience with it that I could install Gentoo in my sleep with my hands tied behind my back.
The problem is one of maintenance. With Debian or RedHat or Mandriva or almost any other Linux distribution, there's a specific version. A line in the sand, if you will, which states "this is what version we're dealing with".
Gentoo gets rid of all that, in favour of individual packages being marked stable/masked ("unstable")/hard masked ("very unstable, will break things, you have been warned"). In theory, you never have to do a major version upgrade of a Gentoo system. You just install everything that's marked stable that you want, if you need something specific that hasn't been marked stable you unmask it. A bit like running Debian Stable with the odd package from the testing branch.
This sounds great, until I now point out the problem.... Gentoo suffers from bit rot. Before you mark me down as a troll, let me explain. Packages still turnover as they age. Eventually, packages are marked obsolete - ie. dropped from portage altogether - and unless you've already taken account of this possibility, once that happens it's a bugger to reinstall them. And once a package is dropped because it's obsolete, sooner or later other packages won't take account of the older versions quirks and version dependencies become at least partly down to luck. Good luck rebuilding a system which has failed with the exact same versions of all the packages it had on there - if it's not been updated in a while and you haven't accounted for such a possibility, the task is to all practical purposes impossible. Combine this with package QA which frankly is nothing like that of Debian - "Stable" generally means "It doesn't cause anyones individual PC to keel over horribly", not "It plays nicely with everything else in the network like it's suppsoed to" - and you've got a recipe for long drawn-out pain if you're trying to run Gentoo on anything more than a few systems.
The only solutions that I've found are:
Note that I've omitted "keep a copy of every package you install" or "make a note of the version of every package you install". These are effectively useless because ebuilds frequently use the packages sourceforge site to download the code from, and if the package moves or the version that you have in your (old) copy of the portage database is removed from sourceforge, you can't install that package and you've got to do an emerge --sync to get an updated ebuild (and an updated everything else in the process). It's not like any other distribution where the mirrors keep a copy of every package so it doesn't much matter if the upstream server on which the project is hosted breaks somehow. Unless you keep every package from day 1 complete with all its dep
That methodolgy won't scale terribly well if you ship more than a handful of CDs. And the risks are huge - not only are you likely to wind up pissing any customers whose CD does get taken by customs, you're also in contempt of court as regards the UK judgement and thus in even hotter legal water.
But it's not the taxes that concern Adobe, the BPI or whoever. The taxes go to the government. What concerns the BPI is that the organisation I'm buying the product from makes it trivially easy for me to buy the product for substantially less money - much of the money I save would otherwise have gone to them. This is more commonly known as "grey market" goods.
The general solution is to make life difficult for companies which choose to sell me the product for substantially less money. Let's pretend I'm the company that's dealing in grey market goods - various techniques exist to make my life difficult:
I very much doubt every little shop selling Levi jeans up and down the country has a license to use Levi's trademark - but that doesn't bother Levi Strauss as long as the shop is selling UK-sourced goods for UK prices. As soon as I come on the scene though, selling US-sourced jeans at US prices to UK customers, I'm sued for trademark infringement. I can continue to sell Levi jeans at a knockdown price - but I can't use the name Levi or their logo anywhere in my advertising material. Good luck selling Levi jeans when the most you can do is advertise them as "Famous Brand!!oneone11!" - you'll look like a cheap, nasty ripoff shop selling fake goods which nobody who would generally buy Levis will go within a hundred miles of. In short, exactly what Levis want.
So short-sighted when developing CDs?
CDs were developed in the late 1970's/early 1980's. The Internet as we know it didn't exist (no DNS or WWW), international phone calls were damn expensive and shipping costs to get a single CD from halfway across the globe were insane compared with today.
The idea that there might be a booming trade in companies selling CDs individually to private customers, shipping each disc individually from Hong Kong to the UK, and doing so substantially cheaper than UK record shops could sell CDs for (even after including postage costs) would have been laughable.
What assets does a company like that need? A computer system to handle orders, an office to site it, a warehouse for stock (nether of which are likely to be owned by the company in the first place) and that's about it AFAICT.
and fly it to the other side of the eastern hemisphere
But, my goodness, if you live due West of Greenwich, then it gets damn expensive.