Bingo. If there's any story here, it's that Microsoft's reputation is so bad that people won't believe them even when they're right.
Maybe they don't believe them because they can't understand them. Maybe it has something to do with Microsoft somehow thinking that sentences like "To the very best of the collective ecosystem knowledge, Windows 7 is correctly warning batteries that are in fact failing and Windows 7 is neither incorrectly reporting on battery status nor in any way whatsoever causing batteries to reach this state" mean something.
Microsoft has gotten really bad at communicating in plain English in recent years. It's been a while since I saw an official communication from Microsoft that I could understand without some frowning and head scratching.
They solicited input from each other and in a blog post that generated a handful of responses. They did this to eliminate "a class of bugs" in the new editor that was triggered by setting the two numbers to different values. Which means they had a bunch of bugs (probably due to confusion between the two settings in the code) and someone had the brilliant idea that the bugs will go away if they just crippled the editor in such a way that the bugs will never be triggered. They solicited input, very quietly, and did it. This also means that the workaround they offer (writing a fucking extension, for fucking crying out loud - what is this, emacs?) will trigger all those bugs because they didn't fix them.
Wine didn't always have that separation between X and the Win32 API. It took quite some time for the project to reach the point where it would have been feasible to take just the Win32 specific parts and plug them into ReactOS. Specifically, 11 years ago it would have made a lot more sense to design things the way the ReactOS ended up implementing their Win32 layer rather than use use Wine's implementation.
I've been following both projects for many years (since 1994 or so for Wine) and neither project made the colossal mistakes that people seem to think that they did - it may seem that way in hindsight, but given what was available at the time when the decisions were made, they made perfect sense.
Wine won out in the marketplace because its design allowed it to get some applications running with relatively little work. Getting every last detail of the Windows platform implemented proved to be very difficult, though. ReactOS promised to offer a way to solve those last niggly details relatively easily, but the need to solve them was pushed so far into the future that nobody found the idea all that exciting. Plus, just getting a usable desktop environment running with ReactOS proved to be a massive undertaking, one that the Wine project didn't have to tackle at all. Add to that the work needed to write drivers for real hardware, a minimal set of tools that you'd need to run ReactOS as your OS, and probably a few hundreds of really important pieces that you would need to get anything done with it, and you're looking at a huge amount of work.
Even if ReactOS never ends up as a viable desktop OS, I can see a possible future for it as the Windows NT replacement of choice for embedded systems, similar to what FreeDOS ended up.
> But dont worry ! the kernel didnt crash ! so it all must be fine !
It is fine in the sense that any files that weren't open by GNOME applications are safe, and that the file system isn't corrupt. It's no consolation when it happens and annoys you, though.
The problem with Linux on the desktop is that nobody has a clear stake in making it work well and the resources necessary to pull it off. There are plenty of companies that make money in the server space and therefore have the incentive to make server stuff work, but nobody is making significant money (as far as I know) in the consumer desktop market, where people are likely to need to run full screen games, so you end up with beta quality software, at best.
I agree about your duct tape remark. I do feel that it's high quality duct tape, with floral prints and scented sticky side. And if it breaks, why, we'll give you another roll for free so you can fix it.
Overall, I'm much happier to use Linux, warts and all, than Windows, which isn't supposed to have the warts, has them anyway, and when you report them to Microsoft they just close the bug report.
But not every product is equally complex. I can't think of a feature that's critical to the proper basic administration of a Unix network that's equally poorly understood, to the point that it's considered news when someone figures it out after 10 years.
The feeling I often get when developing for Microsoft's platform is that it is gratuitously complex. Complex APIs are routinely replaced with new, more complex ones. API calls that take a dozen or so arguments, with some of them pointing to structures containing dozens of members, return error codes that complain of a bad argument - good luck finding out which one of the 30 or so the system found to be offensive. Bugs go unfixed for years. It's all rather unpleasant, really.
Doesn't it bother anyone else that even Microsoft doesn't have a clue how the OS they developed works anymore? That something like this is even an issue?
This is an archive of his old.plan updates in blog form. I know that the actual.plan updates are archived somewhere on www.bluesnews.com, but I can't figure out where they are. That post just mentions that he started working on it, but there's no followup there. I do remember reading a followup somewhere else some time later, and he mentioned the latency issue.
The latency had nothing to do with the CPU speed, and everything to do with the camera buffering a couple of frames before sending them on the bus. Granted, cameras are better today, but I can still see the latency. At this point, it's probably acceptable for most applications, but people tend to notice latency in games more than they would in other applications.
My setup isn't that cheap, I would guess that most people's setups would be cheaper, and I don't see how you can speculate on the amount of lag I'm experiencing when all I said was that it was noticeable, which it is.
Anyway - if you want to implement it, go right ahead. Don't let some guy on Slashdot stop you.
The lag wasn't due to CPU speed - it was due to cumulative delays in the webcam itself, the USB bus, and only a tiny bit of image processing. I think his analysis was done on his.plan proto-blog, way back. I have no idea where it might be archived these days.
I know that even today, when capturing video from a USB camera, I can see a noticeable delay between when I move an object and when I see it moving on the screen, so I don't think that much changed since then. The only video capture setup I'm aware of that doesn't suffer from this problem is when you capture video via a PCI capture card at a high frame rate, and most people don't bother to set something like this up.
I think falcon5768 refers to the DMCA, and to the fact that to install OS X on non-Apple hardware you must circumvent the copy protection, which you're not allowed to do or instruct others about.
I follow the discussions on the Openmoko mailing lists, and people are just starting to discuss a possible port. If anyone got it to run already, they must have kept it a secret from the rest of the world. Except you, evidently.
I'm afraid Koolu is jumping ahead of itself. November is less than two weeks away, which doesn't sound like enough time to port all the code to a new platform if something goes wrong. If everything goes smoothly - sure. But software is rarely that simple. But then, maybe they know something I don't.
I'd love to see it happen - I own a Freerunner, and I'd like to have more options and the kind of stability and usability on it I got from my first Linux machine in 1991...
I wouldn't say the Freerunner is "light years" behind the G1. The CPU is an earlier revision of the ARM architecture, there's plenty of memory, the phone has WiFi, GPS, Bluetooth, accelerometers, a nice VGA resolution screen, it supports uSD cards for storage... And the hardware is as open and documented as any GSM phone is ever likely to be - more than the G1, most likely.
The reason earlier attempts to port the Android stack to the Freerunner failed was that the source wasn't available, and the binaries Google provided were compiled for ARMv5, not ARMv4. With the source now being available, there's a good chance Android will run on the Freerunner.
As far as I remember, Eliza actually did some grammatical reversal - it had a few templates it would use to do it, and if your sentences fit any of those templates the results could be really convincing, something which Elbot (the winning entry) doesn't quite manage. Ever - it simply refuses to pay attention to anything you say in more than the most cursory fashion, which isn't a very effective way of pretending to be human. I just wonder how bad the other programs had to be to rank even lower than that.
Slashdot Mirror
Bingo. If there's any story here, it's that Microsoft's reputation is so bad that people won't believe them even when they're right.
Maybe they don't believe them because they can't understand them. Maybe it has something to do with Microsoft somehow thinking that sentences like "To the very best of the collective ecosystem knowledge, Windows 7 is correctly warning batteries that are in fact failing and Windows 7 is neither incorrectly reporting on battery status nor in any way whatsoever causing batteries to reach this state" mean something.
Microsoft has gotten really bad at communicating in plain English in recent years. It's been a while since I saw an official communication from Microsoft that I could understand without some frowning and head scratching.
B12?
No.
They solicited input from each other and in a blog post that generated a handful of responses. They did this to eliminate "a class of bugs" in the new editor that was triggered by setting the two numbers to different values. Which means they had a bunch of bugs (probably due to confusion between the two settings in the code) and someone had the brilliant idea that the bugs will go away if they just crippled the editor in such a way that the bugs will never be triggered. They solicited input, very quietly, and did it. This also means that the workaround they offer (writing a fucking extension, for fucking crying out loud - what is this, emacs?) will trigger all those bugs because they didn't fix them.
Idiots.
Wine didn't always have that separation between X and the Win32 API. It took quite some time for the project to reach the point where it would have been feasible to take just the Win32 specific parts and plug them into ReactOS. Specifically, 11 years ago it would have made a lot more sense to design things the way the ReactOS ended up implementing their Win32 layer rather than use use Wine's implementation.
I've been following both projects for many years (since 1994 or so for Wine) and neither project made the colossal mistakes that people seem to think that they did - it may seem that way in hindsight, but given what was available at the time when the decisions were made, they made perfect sense.
Wine won out in the marketplace because its design allowed it to get some applications running with relatively little work. Getting every last detail of the Windows platform implemented proved to be very difficult, though. ReactOS promised to offer a way to solve those last niggly details relatively easily, but the need to solve them was pushed so far into the future that nobody found the idea all that exciting. Plus, just getting a usable desktop environment running with ReactOS proved to be a massive undertaking, one that the Wine project didn't have to tackle at all. Add to that the work needed to write drivers for real hardware, a minimal set of tools that you'd need to run ReactOS as your OS, and probably a few hundreds of really important pieces that you would need to get anything done with it, and you're looking at a huge amount of work.
Even if ReactOS never ends up as a viable desktop OS, I can see a possible future for it as the Windows NT replacement of choice for embedded systems, similar to what FreeDOS ended up.
That's OK - I remember when the announcement about registering user accounts was at the top of the home page and I thought: "Nah."
It took me about a month to register, if I'm not mistaken. I could have had a 2 digit UID, and life would have been... Pretty much the same, actually.
What low UID?
> But dont worry ! the kernel didnt crash ! so it all must be fine !
It is fine in the sense that any files that weren't open by GNOME applications are safe, and that the file system isn't corrupt. It's no consolation when it happens and annoys you, though.
The problem with Linux on the desktop is that nobody has a clear stake in making it work well and the resources necessary to pull it off. There are plenty of companies that make money in the server space and therefore have the incentive to make server stuff work, but nobody is making significant money (as far as I know) in the consumer desktop market, where people are likely to need to run full screen games, so you end up with beta quality software, at best.
I agree about your duct tape remark. I do feel that it's high quality duct tape, with floral prints and scented sticky side. And if it breaks, why, we'll give you another roll for free so you can fix it.
Overall, I'm much happier to use Linux, warts and all, than Windows, which isn't supposed to have the warts, has them anyway, and when you report them to Microsoft they just close the bug report.
But not every product is equally complex. I can't think of a feature that's critical to the proper basic administration of a Unix network that's equally poorly understood, to the point that it's considered news when someone figures it out after 10 years.
The feeling I often get when developing for Microsoft's platform is that it is gratuitously complex. Complex APIs are routinely replaced with new, more complex ones. API calls that take a dozen or so arguments, with some of them pointing to structures containing dozens of members, return error codes that complain of a bad argument - good luck finding out which one of the 30 or so the system found to be offensive. Bugs go unfixed for years. It's all rather unpleasant, really.
Doesn't it bother anyone else that even Microsoft doesn't have a clue how the OS they developed works anymore? That something like this is even an issue?
Skype is profitable, according to eBay.
Sperm banks? West Banks? Bankruptcy Help Club for Men? Anne Bankroft? (Yeah, I know...)
Go read it.
Sorry, can't find the place where I saw this. The closest I came was this:
http://doom-ed.com/blog/1999/11
This is an archive of his old .plan updates in blog form. I know that the actual .plan updates are archived somewhere on www.bluesnews.com, but I can't figure out where they are. That post just mentions that he started working on it, but there's no followup there. I do remember reading a followup somewhere else some time later, and he mentioned the latency issue.
The latency had nothing to do with the CPU speed, and everything to do with the camera buffering a couple of frames before sending them on the bus. Granted, cameras are better today, but I can still see the latency. At this point, it's probably acceptable for most applications, but people tend to notice latency in games more than they would in other applications.
My setup isn't that cheap, I would guess that most people's setups would be cheaper, and I don't see how you can speculate on the amount of lag I'm experiencing when all I said was that it was noticeable, which it is.
Anyway - if you want to implement it, go right ahead. Don't let some guy on Slashdot stop you.
The lag wasn't due to CPU speed - it was due to cumulative delays in the webcam itself, the USB bus, and only a tiny bit of image processing. I think his analysis was done on his .plan proto-blog, way back. I have no idea where it might be archived these days.
I know that even today, when capturing video from a USB camera, I can see a noticeable delay between when I move an object and when I see it moving on the screen, so I don't think that much changed since then. The only video capture setup I'm aware of that doesn't suffer from this problem is when you capture video via a PCI capture card at a high frame rate, and most people don't bother to set something like this up.
John Carmack prototyped this a few years back. His conclusion at the time was that there was too much lag in the system to make it really useful.
I think falcon5768 refers to the DMCA, and to the fact that to install OS X on non-Apple hardware you must circumvent the copy protection, which you're not allowed to do or instruct others about.
Really? Where?
I follow the discussions on the Openmoko mailing lists, and people are just starting to discuss a possible port. If anyone got it to run already, they must have kept it a secret from the rest of the world. Except you, evidently.
No, not really. Why?
I'm afraid Koolu is jumping ahead of itself. November is less than two weeks away, which doesn't sound like enough time to port all the code to a new platform if something goes wrong. If everything goes smoothly - sure. But software is rarely that simple. But then, maybe they know something I don't.
I'd love to see it happen - I own a Freerunner, and I'd like to have more options and the kind of stability and usability on it I got from my first Linux machine in 1991...
I wouldn't say the Freerunner is "light years" behind the G1. The CPU is an earlier revision of the ARM architecture, there's plenty of memory, the phone has WiFi, GPS, Bluetooth, accelerometers, a nice VGA resolution screen, it supports uSD cards for storage... And the hardware is as open and documented as any GSM phone is ever likely to be - more than the G1, most likely.
The reason earlier attempts to port the Android stack to the Freerunner failed was that the source wasn't available, and the binaries Google provided were compiled for ARMv5, not ARMv4. With the source now being available, there's a good chance Android will run on the Freerunner.
As far as I remember, Eliza actually did some grammatical reversal - it had a few templates it would use to do it, and if your sentences fit any of those templates the results could be really convincing, something which Elbot (the winning entry) doesn't quite manage. Ever - it simply refuses to pay attention to anything you say in more than the most cursory fashion, which isn't a very effective way of pretending to be human. I just wonder how bad the other programs had to be to rank even lower than that.
Hey, even Eliza was better. That's pretty sad.
Have you tried the winning program mentioned in the article? It appears to do exactly that.
Allow me to correct myself: SLUDGE is open source, it turns out. That's a pretty recent development.