Back in the days of the 386sx, the only reason for more video RAM was so you could get more color depth at a certain resolution
Us Amiga users would like to loudly disagree and point out that our video hardware could do more than one video plane at a time and use the video memory (O.K, chip RAM) for things like sprites. 512k/1MB/2MB never seemed enough.
To be fair, Dell ship Ubuntu 8.04 LTS and he may have a valid reason not to want to break away from the long term support.
Re:The Achilles heel of this...
on
Phoenix BIOSOS?
·
· Score: 1
Someone still has to sit down and make the decision to write and test a new driver for a fast-fading piece of legacy hardware -
and if he says the hell with it, there is not much you can do.
You can do it yourself, or find someone to do it for you. Because you have the source. Which is sort of the point here.
Re:The Achilles heel of this...
on
Phoenix BIOSOS?
·
· Score: 1
You rebuild your kernel to build a kernel module? You're doing something very wrong.
This is my point. Fusion plants aren't going to be cheap to build either, not to mention the return on the vast investment so far they will require. Refining fusion fuel wont be cheap, either. Unless we all get Mr. Fusions in our basements, power that is "so cheap it's free" will remain out of reach for some time.
If you're scared of the GPL you don't even need to look at the source, even. Just enter a bunch of formulas in a sheet, save it and open the XML in a text editor to see how they're stored. Microsoft didn't even need to do that because the already have a plugin that can read & parse ODF/OO.o formulas!
The current spec doesn't cover spreadsheet formulas: it has a big whole and basically says "Do what OpenOffice.org does for now". ODF 1.2 will cover spreadsheet formulas but it isn't finished yet. So yes, it is valid to say "Well the spec doesn't cover formulas, not Microsofts fault".
Except...Microsoft already have a perfectly good plugin that can read & write ODF documents. It appears they've gone out of their way to break that existing code and do things differently to how everyone else (including themselves) are already doing things. As the author of the blog says "If your business model requires only conformance and not actually achieving interoperability, then I wish you well.".
If Microsoft have put all that effort into adding ODF support without actually achieving interoperability then it's a thinly veiled paper exercise on their part.
Yes but Microsoft said that it'd be different this time and they've changed, they really have, and they don't mean to hurt you but baby you just don't understand that when you can't keep your pretty little mouth shut then sometimes need a slap for your own good.
I might be confusing Microsoft with a wife beater, but the mentality is roughly the same it seems.
AmigaOS couldn't separate anything from anything because it didn't have memory protection, which it didn't have because the original hardware (Motorola 68000) didn't have it. Then once MMUs became available in newer CPUs (68030/040/060) the OS couldn't be changed because applications relied on it.
The problem with driver isolation is that it's a layering violation given most today's PC hardware.
That depends on how you've designed things, I guess. "Today's PC hardware" (& yesterdays for that matter) has always provided 4 protection ring levels, but very few OSes have ever made use of more than 2 (1 for the kernel, one for userspace). You could certainly put drivers in a higher ring than the kernel and allow them to only have limited access to memory, just as you do with a user-space application.
No, grandparent implied that you can apply updates on a gazillion hosts automatically....You will create your own update repo and configure them all to update automatically from it.
Sure, you will. So would I. It seems you sort of forgot to mention that in your original post, though. If you simply start yum on your server it'll use the default yum.conf/yum.conf.d setup, which will be the global repository. You've massively over-simplified your answer to the submitters question, which isn't very helpful for the submitter.
Er, not really, but whatever. GP asked "Why would you mindlessly update packages on a server when there's no actual reason to do so?" and you've responded in a way that implies the answer bears little relation to the question. That's O.K though, this is Slashdot. I don't expect anyone to respond to a thread in a coherent manner.
Yes but that implies you are not "mindlessly updating packages": you're carefully controlling the packages that are available via. your local YUM repository. The grandparent seems to be implying that you should just switch on YUM & cronjob it to pull every available update from the global YUM repo, on every server, which is clearly a bad idea.
Yes, but sometimes you want there to be manual intervention. For example, I probably don't want YUM (Or up2date, or whatever) to upgrade the kernel, because I'll probably have a surprise the next time I have to reboot the server. especially if I need to install drivers that are not part of the stock kernel.
The same can sometimes be true of other packages: I may not want YUM to upgrade Apache2 on my web server, for example.
So do I, and I've never had any graphics lock up issues with 8.04 or 8.10 with any version of the Intel driver. I'm not suggested that bugs don't exist, but they're perhaps not as universal as you think.
My biggest issue right now is that I have a weird Atheros chipset which means I currently have to use a hacked up Madwifi driver, so I'm hoping 9.04 has an in-tree driver that works for this chip.
Slashdot Mirror
There's also the typo "z-bugger", which made me giggle. Yes, giggle.
Us Amiga users would like to loudly disagree and point out that our video hardware could do more than one video plane at a time and use the video memory (O.K, chip RAM) for things like sprites. 512k/1MB/2MB never seemed enough.
To be fair, Dell ship Ubuntu 8.04 LTS and he may have a valid reason not to want to break away from the long term support.
You rebuild your kernel to build a kernel module? You're doing something very wrong.
This is my point. Fusion plants aren't going to be cheap to build either, not to mention the return on the vast investment so far they will require. Refining fusion fuel wont be cheap, either. Unless we all get Mr. Fusions in our basements, power that is "so cheap it's free" will remain out of reach for some time.
Yes, just like fission power plants would give us electricity "too cheap to meter".
Not being a citizen of the United States of America it's kind of irrelevant what I think of President Obama.
If you're scared of the GPL you don't even need to look at the source, even. Just enter a bunch of formulas in a sheet, save it and open the XML in a text editor to see how they're stored. Microsoft didn't even need to do that because the already have a plugin that can read & parse ODF/OO.o formulas!
That's unfair. Apple have never made an iWorks product intentionally produce a broken ODF document! *cough*
The current spec doesn't cover spreadsheet formulas: it has a big whole and basically says "Do what OpenOffice.org does for now". ODF 1.2 will cover spreadsheet formulas but it isn't finished yet. So yes, it is valid to say "Well the spec doesn't cover formulas, not Microsofts fault".
Except...Microsoft already have a perfectly good plugin that can read & write ODF documents. It appears they've gone out of their way to break that existing code and do things differently to how everyone else (including themselves) are already doing things. As the author of the blog says "If your business model requires only conformance and not actually achieving interoperability, then I wish you well.".
If Microsoft have put all that effort into adding ODF support without actually achieving interoperability then it's a thinly veiled paper exercise on their part.
Yes but Microsoft said that it'd be different this time and they've changed, they really have, and they don't mean to hurt you but baby you just don't understand that when you can't keep your pretty little mouth shut then sometimes need a slap for your own good.
I might be confusing Microsoft with a wife beater, but the mentality is roughly the same it seems.
A HAL is a long way from a virtual machine.
Again, it depends on how you've designed things. What if your hypothetical OS forced all shared hardware accesses via. it's own HAL?
AmigaOS couldn't separate anything from anything because it didn't have memory protection, which it didn't have because the original hardware (Motorola 68000) didn't have it. Then once MMUs became available in newer CPUs (68030/040/060) the OS couldn't be changed because applications relied on it.
BeOS isn't a micro kernel either, and nor is Syllable. Both use message passing heavily in user space but that's a different beast.
That depends on how you've designed things, I guess. "Today's PC hardware" (& yesterdays for that matter) has always provided 4 protection ring levels, but very few OSes have ever made use of more than 2 (1 for the kernel, one for userspace). You could certainly put drivers in a higher ring than the kernel and allow them to only have limited access to memory, just as you do with a user-space application.
OS X is as much a microkernel as Windows NT I.e. it isn't one.
Yeah, like making computer software that doesn't fail.
Sure, you will. So would I. It seems you sort of forgot to mention that in your original post, though. If you simply start yum on your server it'll use the default yum.conf/yum.conf.d setup, which will be the global repository. You've massively over-simplified your answer to the submitters question, which isn't very helpful for the submitter.
Er, not really, but whatever. GP asked "Why would you mindlessly update packages on a server when there's no actual reason to do so?" and you've responded in a way that implies the answer bears little relation to the question. That's O.K though, this is Slashdot. I don't expect anyone to respond to a thread in a coherent manner.
Yes but that implies you are not "mindlessly updating packages": you're carefully controlling the packages that are available via. your local YUM repository. The grandparent seems to be implying that you should just switch on YUM & cronjob it to pull every available update from the global YUM repo, on every server, which is clearly a bad idea.
Yes, but sometimes you want there to be manual intervention. For example, I probably don't want YUM (Or up2date, or whatever) to upgrade the kernel, because I'll probably have a surprise the next time I have to reboot the server. especially if I need to install drivers that are not part of the stock kernel.
The same can sometimes be true of other packages: I may not want YUM to upgrade Apache2 on my web server, for example.
If it wasn't for Real I'd have to stream BBC Radio 1 in Microsoft WMA format. Be careful what you wish for.
So do I, and I've never had any graphics lock up issues with 8.04 or 8.10 with any version of the Intel driver. I'm not suggested that bugs don't exist, but they're perhaps not as universal as you think.
My biggest issue right now is that I have a weird Atheros chipset which means I currently have to use a hacked up Madwifi driver, so I'm hoping 9.04 has an in-tree driver that works for this chip.