surely any well-written code for a portable operating system, such as Linux, should be written in such a way that endianness and word size is irrelevant?
I would have thought that fiddling with bitwise data structures on disk is pretty much one of the cases where endianness and word size is very relevant. I mean, I could be wrong.
In fact, these days you'd pretty much have to go out of your way to ensure that it didn't work.
Hmm. Let's try reading a 32-bit value from the disk surface and masking out the top 3 bits (random file-systemesque example chosen off the top of my head). Yep, I reckon you'd have to go out of your way to make sure that it did work across platforms with different word size or endianness. It's not exactly hard, but you'd certainly have to go out of your way.
Especially as I'm guessing the number of times this driver has been run on a Linux PC that is not a 32-bit Intel x86 machine is currently close to zero, given the typical application of this software.
I changed the motherboard in my Windows machine once, but didn't reinstall the OS straight away - was curious if it would 'just work'.
I was running a dual boot Windows 98 and Windows 2000 system.
Windows 98 booted up and said "Crikey chief! It's all changed!", then had a bit of a scurry, and rebooted.
Then it did it again.
And again. And again. And again.
Then it worked.
After 5 reboots all my hardware had been auto-detected and configured, and Windows 98 was ready to go. I never had any problems with the installation after that.
Then I booted to Windows 2000. It crashed out in the text mode boot screens and died in a flaming heap, telling me I'd committed some heinous act or other. I never got it past that. In the end I did a clean install of Windows 2000.
I was impressed with 98, not so much with 2000. Surprising, as I'd fully expected the opposite result.
I'm not sure how that would work. Rootkits are generally pieces of software that hide themselves to avoid detection of the intrusion. How would a typesafe language prevent that? Why would being typesafe even help? How will being typesafe prevent the installation of rootkits via social engineering methods, etc.?
Can't see it myself. But then I tend to assume that when people use words like 'not possible' they mean it. Or is this the marketing definition of impossible?:-)
Is there any particular reason you believe that writing an OS in a typesafe language would make rootkits impossible? Or are you implying something else?
GPUs would push polygons and shaders which is what they do best, and the monitor could use some kind of algorithm to pretty-up textures, reduce jaggy edges, and smooth fonts.
Before you even started to program a complex FPS game, you might start by carefully separating the layers and keeping things like two dimensional surfaces rendered to be de-coupled from other things like the AI of the enemies.
This is ludicrous - cloud cuckoo land. My texture mapping code is intimately bound up in the AI of the enemies.
It's simply not possible to separate these two deeply entwined concepts.
As Jason Rubin phrased it (in his now moderately infamous call-to-arms speech):
Imagine there are two 747s taking off. One of them is full of the best games developers in the world - coders, artists, designers. The other is full of the best marketing and PR people in the games industry. Now imagine one of these planes crashes. Which plane crash would be the biggest disaster for the games industry?
Yay - it's refreshing to see someone working for 'the other side' (for want of a better term) who reacts to this story in a realistic and honest way, without feeling the need to bash MS for their WinFS problems ("Ha ha! M$ are teh suck!", etc).
Perhaps, I don't know, it's because you've spent years working on this problem, and know the difficulties involved, rather than the average slashdot MS basher who read a magazine article about writing file systems once and can't see what's so hard about them, or, come to that, like some of the other posters here, who can't see what's so hard about managing one of the largest software projects on the planet.
They're just going to have to bite the bullet sooner or later and do what Apple did-- drop the old OS in favor of a new one, and ease the transition to it by allowing the old one to run as an application.
Yeah, they should write a new system - let's call it the NT kernel and Win32 subsystem, and then give the applications written for the old OS an emulation/thunking layer - let's call it Wowexec, for instance, and then the old applications written for the old crufty OS could gradually be phased out.
Since someone will have to make a software only player that will need to work with XP and DirectX it will be no problem to use the samplegrabber to rip the video.
And the only way to defeat this would be if Microsoft somehow had the source code to DirectX and Windows, and changed them to release an update that required signed drivers to playback protected content, etc. An update that would be required by any software HD-DVD or BluRay players, of course.
I used to work on a helpdesk for BT (UK phone provider). One of my favourite incidents was when we were called out to fix someone's PC that was overheating. According to the fault report, it was "Overheating due to having too many files in the root directory".
What had actually happened was a hardware engineer had been called out to look at the PC overheating, and as part of his routine checks had looked at the hard drive. There were quite a few data files in C:\, and the engineer had mentioned that they might want to fix that (this was in FAT12/DOS 3.x days when you could only have 128 - I think? - files in the root folder). A fair point - if the user hit the limit they'd probably get confused - but for some reason the user interpreted this as being the cause of overheating. And that's a software problem, so they called us.
Another good one was a fault reported on a Sinclair ZX Spectrum that was being used for some critical purpose in a telephone exchange, and could we take a look at it? Be very afraid.
On a related note, we also dealt with ordering new kit. We used to get a few requests for a Zenith laptop from phone engineers for testing lines, etc - because it was good for playing this 3D golf game that was doing the rounds. Requests for this were usually denied by management, because they see that the guy just wanted a laptop to play with. In response to the denial (and more often, as a first line of attack as people got wise to this), they would opt to order a 'Tester 4A' instead, which also allowed them to test phone lines/systems. Orders for a Tester 4A were always approved by management - with, I like to imagine, a harrumphing grunt of approval that here was an engineer that was actually interested in doing their job for a change, dammit.
Now, I'm sure you can guess what a 'Tester 4A' actually was:-)
I worked in a computer shop when I was young, and some guy brought in a disk he wanted us to look at (can't remember what was on it) - when we said ok, he took it out of his back pocket. It was a 5.25" floppy, folded neatly into four. I don't think I will surprise anyone here when I say it didn't work.
Slashdot Mirror
All jokes aside, this is slashdot, so I'm not sure you actually needed to explain why playing vinyl records in a car doesn't work that well :-)
("You must be new here" comment in 5...4...3...)
I refer you to your original comment:
and then your supplied code:
That code looks like it's going out of its way to deal with endian issues to me.
As I said, it's not hard, but it's not free either. Perhaps we should just agree that your original comment was hyperbole and leave it at that.
I would have thought that fiddling with bitwise data structures on disk is pretty much one of the cases where endianness and word size is very relevant. I mean, I could be wrong.
Hmm. Let's try reading a 32-bit value from the disk surface and masking out the top 3 bits (random file-systemesque example chosen off the top of my head). Yep, I reckon you'd have to go out of your way to make sure that it did work across platforms with different word size or endianness. It's not exactly hard, but you'd certainly have to go out of your way.
Especially as I'm guessing the number of times this driver has been run on a Linux PC that is not a 32-bit Intel x86 machine is currently close to zero, given the typical application of this software.
I changed the motherboard in my Windows machine once, but didn't reinstall the OS straight away - was curious if it would 'just work'.
I was running a dual boot Windows 98 and Windows 2000 system.
Windows 98 booted up and said "Crikey chief! It's all changed!", then had a bit of a scurry, and rebooted.
Then it did it again.
And again. And again. And again.
Then it worked.
After 5 reboots all my hardware had been auto-detected and configured, and Windows 98 was ready to go. I never had any problems with the installation after that.
Then I booted to Windows 2000. It crashed out in the text mode boot screens and died in a flaming heap, telling me I'd committed some heinous act or other. I never got it past that. In the end I did a clean install of Windows 2000.
I was impressed with 98, not so much with 2000. Surprising, as I'd fully expected the opposite result.
That's probably why nVidia and ATi did that.
I'm not sure how that would work. Rootkits are generally pieces of software that hide themselves to avoid detection of the intrusion. How would a typesafe language prevent that? Why would being typesafe even help? How will being typesafe prevent the installation of rootkits via social engineering methods, etc.?
Can't see it myself. But then I tend to assume that when people use words like 'not possible' they mean it. Or is this the marketing definition of impossible? :-)
Is there any particular reason you believe that writing an OS in a typesafe language would make rootkits impossible? Or are you implying something else?
That depends on who's in the driving seat.
It's called a TV.
This is ludicrous - cloud cuckoo land. My texture mapping code is intimately bound up in the AI of the enemies.
It's simply not possible to separate these two deeply entwined concepts.
Well, presumably at least below room temperature.
That was a legacy from Acorn DFS on the BBC Micro.
Er, yes. Gaze upon my icon validation string hacks, ye mighty, and despair!
'Pretty much' predated Windows?
By that do you mean that Windows 1.0 was launched in 1985, and Arthur was launched in 1987?
We can but hope.
Er...
As Jason Rubin phrased it (in his now moderately infamous call-to-arms speech):
Imagine there are two 747s taking off. One of them is full of the best games developers in the world - coders, artists, designers. The other is full of the best marketing and PR people in the games industry. Now imagine one of these planes crashes. Which plane crash would be the biggest disaster for the games industry?
Yay - it's refreshing to see someone working for 'the other side' (for want of a better term) who reacts to this story in a realistic and honest way, without feeling the need to bash MS for their WinFS problems ("Ha ha! M$ are teh suck!", etc).
Perhaps, I don't know, it's because you've spent years working on this problem, and know the difficulties involved, rather than the average slashdot MS basher who read a magazine article about writing file systems once and can't see what's so hard about them, or, come to that, like some of the other posters here, who can't see what's so hard about managing one of the largest software projects on the planet.
Yeah, they should write a new system - let's call it the NT kernel and Win32 subsystem, and then give the applications written for the old OS an emulation/thunking layer - let's call it Wowexec, for instance, and then the old applications written for the old crufty OS could gradually be phased out.
But I guess we'll never see that.
And then there's the Aston Martin, the Dom Perignon, and hell, when I last watched Goldfinger they were whoring Slazenger golf balls, ffs.
And the only way to defeat this would be if Microsoft somehow had the source code to DirectX and Windows, and changed them to release an update that required signed drivers to playback protected content, etc. An update that would be required by any software HD-DVD or BluRay players, of course.
Compare and contrast:
with:
...unless they spent 3 years just talking about it. Hey, this is an open source project, right..? Hm...
I used to work on a helpdesk for BT (UK phone provider). One of my favourite incidents was when we were called out to fix someone's PC that was overheating. According to the fault report, it was "Overheating due to having too many files in the root directory".
What had actually happened was a hardware engineer had been called out to look at the PC overheating, and as part of his routine checks had looked at the hard drive. There were quite a few data files in C:\, and the engineer had mentioned that they might want to fix that (this was in FAT12/DOS 3.x days when you could only have 128 - I think? - files in the root folder). A fair point - if the user hit the limit they'd probably get confused - but for some reason the user interpreted this as being the cause of overheating. And that's a software problem, so they called us.
Another good one was a fault reported on a Sinclair ZX Spectrum that was being used for some critical purpose in a telephone exchange, and could we take a look at it? Be very afraid.
On a related note, we also dealt with ordering new kit. We used to get a few requests for a Zenith laptop from phone engineers for testing lines, etc - because it was good for playing this 3D golf game that was doing the rounds. Requests for this were usually denied by management, because they see that the guy just wanted a laptop to play with. In response to the denial (and more often, as a first line of attack as people got wise to this), they would opt to order a 'Tester 4A' instead, which also allowed them to test phone lines/systems. Orders for a Tester 4A were always approved by management - with, I like to imagine, a harrumphing grunt of approval that here was an engineer that was actually interested in doing their job for a change, dammit.
Now, I'm sure you can guess what a 'Tester 4A' actually was :-)
Sometimes you get the opposite problem (see last sentence of that tip).
Mac users, eh? ;-)
I worked in a computer shop when I was young, and some guy brought in a disk he wanted us to look at (can't remember what was on it) - when we said ok, he took it out of his back pocket. It was a 5.25" floppy, folded neatly into four. I don't think I will surprise anyone here when I say it didn't work.
Or if you're really unlucky you get a bunch of mad Scotsmen from the 22nd Regiment on your balcony. It always seems to go downhill from there.
Well, in that case, feel free to download the current cddb/GraceNote database, start your own CD database service with it, and see how far you get. :-)