That makes a lot more sense. I probably should have RTFA before commenting. (Not that I know TFA covers this bit, because I still haven't read it. But whatever.)
Wait, forget using it on multiple machines. Does this suggest that you need to plug your iPod into ANY machine to charge it? You can't just plug it into the wall?
If this is true, it seems like a really retarded idea to me. The times when I want an iPod the most -- when I'm on a trip -- are exactly the times when I'm not going to be near my machine and exactly the time when I'll need to charge it more.
But do programs running under SUA have access to sockets? If so, they can run as clients of an X server that uses the Windows API.
It's still not perfect. X programs have weirdnesses that native ones don't. For instance, if I open a Cygwin Emacs session running with the Cygwin X server, it ignores me if I change my keyboard layout. You don't get native controls, etc.
Essentially this is because SUA is intended just to ease the porting of Unix applications; it's not intended to be a platform for development of new applications. (It's also not clear that it would be a big win to have access to the Windows GUI stuff; why write it to the POSIX API if you're just going to use Windows-specific APIs for the GUI? It's not like there's a standard widget API MS could provide bindings for or anything.)
Then why not make the SFU framework available for download through Microsoft Update, like the.NET framework?
Still the same reason. In fact, I would suggest moreso. I'm sure more people go through Windows Update, even the manually accessed pages, than poke around on Windows CDs. (Especially as they aren't even included in most new computers.) Plus the fact that it's presented as an update rather than just something sitting around on the CD would suggest people would install it.
I don't really see the virtue in most people installing it. People who are tech savvy enough to want it can download it themselves (though it is admittedly not well known), or use Cygwin, which gives you a lot of the same benefits, and a wider selection of packages. (Though not case-sensitivity in the file system, and Cygwin apps seem to load slowly.)
Interns aren't tabula rasa, they're just inexperienced. What background did he have? Any IT schooling? If so, he was aware of what he was doing. All the persons in the chain of command are guilty, even the peons.
So what should he have done? Said "I'm not taking them" and risked getting fired?
He made a mistake, even a somewhat dumb one, but it's at least an understandable one. In his situation I would have taken the tapes too, though I would have kept them in the trunk until getting to my apartment, then taken them inside.
BTW, the post you're replying to was too harsh to be meant for you. Being wrong is fine; everyone's wrong sometimes. It's just that the poster I was replying to (who's currently modded troll) was sort of being an ass about being wrong.
I also tire of the anti-MS slant on Slashdot. I'll be the first to admit that Windows has flaws, and I have from time to time been fairly vocal about some stupidities of its design. That said, I'm one of the seemingly rare CS people who actually likes Windows. (I'm sure a lot of this is familiarity and the fact that I know how to do stuff on Windows, but I'm no stranger to Linux either.) It gets tiresome for people to complain that MS is wrong for every single thing that they do. So the "that sounds like bait and switch" or whatever bugged me a bit.
The reply I made directly to you was the one you were supposed to read.;-)
Um, no. Bait and switch is advertising something then delivering another. MS did deliver it for the versions of Windows for which they advertised it for. And of course this ignores the fact that the OP was wrong about the bit rot bit, and in fact MS has *improved* the POSIX subsystem since they stopped shipping it with Windows, but I wouldn't expect the typical/. poster to actually know that, because it actually makes MS and Windows look a little less bad.
NT did include a POSIX system but that bit-rotted from lack of use and was removed I believe.
The POSIX subsystem is no longer included in Windows distributions, but you can still get it as a free download as part of Services for UNIX (SFU). (You'll also see mention of it as the Interix Subsystem and the Subsystem for UNIX-Based Applications (SUA).)
It is continually being maintained, and MS actually seems to have put an increased (albeit still small) push of it fairly recently. There is a fair suite of programs available for it, including GCC, Bash, automake/conf, SSH, etc., and it was supplanted to (supposedly) be POSIX.2 compliant. (When it shipped with Windows, it only supported POSIX.1.)
The big problem with it is that programs running under SUA can't access Windows API calls. This isn't surprising given the architecture of Windows, but it does mean that, for instance, you can't really have a GUI. I'm also not sure how complete the POSIX support actually is.
Basically I suspect it's a combination of they didn't want to put it on the CD and hence slightly encourage end users to install it (the did this with Windows 98 and TweakUI and Raymond Chen said it turned out to be a disaster for their tech support lines) and the CDs of XP being too full for it.
I misremembered slightly what went wrong my latest point was an attempt to clarify.
The problem wasn't with slipstreaming the SATA driver, but it was caused by other messing around with the setup routine in nLite, specifically turning on some unattended features.
All I was trying to say was that when you start messing around with the setup, it's easy to make things go wrong. Maybe not so much if you're just slipstreaming a couple things, but there are so many checkboxes in nLite that do useful stuff that it's very easy to produce something that won't actually work right for what you want.
Oh yeah, I remember what happened in a little more detail now. At first I decided to not slipstream the SATA driver, but just SP2 + hotfixes and with semi-automatic installation (it fills out fields automatically but you still have to go through to accept them). The reason for this was because the driver is on floppy, and the computer I was doing this on didn't have a floppy drive, so I figured I'd just do the F6 thing at the start. The mix of unattended and floppy-drive loading was what caused the problem I linked to.
I still don't remember what the other problems were, but at one point I did wind up extracting then compressing the raw CAB files for some reason.
I still use a CRT too. I... am too cheap to spend $300 or more on a flat panel*, despite my current monitor approaching its last legs.
* After using 1600x1200 resolution for a few years, I ain't never going back. 1680 by whatever it is that widescreens sometimes are is about my limit in terms of how much smaller I'll accept. This basically means I need a 19", which start at ~$300. And if I got one anyway... I'd probably just put it next to this in a dual monitor setup.
Whether it does or not depends on how your SATA controller presents itself. Does your motherboard have integrated SATA, or are you using an external controller?
If it does turn out to be an issue, you could always play around in a virtual machine. I very strongly doubt VM support for IDE is going anywhere for the foreseeable future.
This CAN take some effort though. I recently did this, slipstreaming (1) my SATA drivers, (2) Service Pack 2, and (3) all the hotfixes since SP2 into my XP CD, and I burned two or three coasters before getting it right. For instance, the first time I also tried to set up a semi-automatic install; but turns out this doesn't interact well with slipstreaming storage drivers like that. I forget what I screwed up after that.
All-in-all it took rather longer than it would have to just do it normally, and I coastered CDs in the process.
So should I remove my TV input card, my NIC, or my sound card to make room?
If you don't have a spare slot, yes, that's a problem.
And will companies continue to make SATA controllers after most PCI slot product lines have been replaced with PCI-e or USB 2.0 equivalents?
That's probably aways down the line. A quick survey shows PCI slots still outnumber PCI-e even on the highest-end mobos. (Though both seem to be in vanishingly small numbers.)
And how do I reinstall an operating system if the setup program doesn't recognize SATA?
If you're referring to Windows, that's what pressing F6 during the start of the textmode setup is for (I suspect you still have a floppy connected, though I could easily be wrong), or you can use nLite to slipstream your SATA drivers. Both solutions will work. If you're talking Linux, it shouldn't be a big issue to get a later revision that supports it.
Look, it's going to be inconvenient if you don't have SATA ports on your motherboard. (As I said in a couple other posts, I'm in that boat too. Though I did have a spare PCI slot.) But you can't reasonably expect companies to support legacy technology forever. It does cost them money to support the two standards, and I doubt they'll lose many sales because of this.
You can get a PCI controller card for $30 or so. I have two SATA drives, and most of my computer (including motherboard) is 5 years old, just as SATA was hitting the market, so I don't have integrated support.
I read back over that link a couple days ago when I saw a reply further down, and I agree that it might be possible to construe it as diversion of services. When I read the page the first time I read it too quickly, and only looked at (a)(1)-(a)(4). And I *don't* see any way to argue that what they did violates anything in paragraph (a).
I don't know enough about the legal terminology or case law to speak to (b)'s applicability. I think it could go either way.
Oh c'mon. You're looking at the uncommon case. Do you really want to suggest that even a sizable minority of the sites you visit on a daily basis use HTTPS?
I visit my banking site a couple times a week. I shop online a couple times a month. I read email online more commonly, but not *that* commonly from a web browser.
By contrast, I visit/. several times a day, I visit Fark a couple times a day, I visit a couple blogs a time or two a day, I visit CNN a couple times a day, I visit a couple other forums a couple times a day each, etc. NONE of these sites use SSL.
I generally agree with you, but I have a counterargument. (Unrelated to the issue of driving while on the phone, which is a whole other can of worms.)
My current phone has a weak '9' button. More than once I have dialed a number quickly and hit send before realizing "d'oh, it didn't register the 9". So in the case of my phone, the tactile feel of the buttons gives a false sense of security. Having to look at the screen anyway would help with that problem.
Slashdot Mirror
I have to say that this is one of the more.. fanciful... posts I've read here in a while.
That makes a lot more sense. I probably should have RTFA before commenting. (Not that I know TFA covers this bit, because I still haven't read it. But whatever.)
Wait, forget using it on multiple machines. Does this suggest that you need to plug your iPod into ANY machine to charge it? You can't just plug it into the wall?
If this is true, it seems like a really retarded idea to me. The times when I want an iPod the most -- when I'm on a trip -- are exactly the times when I'm not going to be near my machine and exactly the time when I'll need to charge it more.
But do programs running under SUA have access to sockets? If so, they can run as clients of an X server that uses the Windows API.
.NET framework?
It's still not perfect. X programs have weirdnesses that native ones don't. For instance, if I open a Cygwin Emacs session running with the Cygwin X server, it ignores me if I change my keyboard layout. You don't get native controls, etc.
Essentially this is because SUA is intended just to ease the porting of Unix applications; it's not intended to be a platform for development of new applications. (It's also not clear that it would be a big win to have access to the Windows GUI stuff; why write it to the POSIX API if you're just going to use Windows-specific APIs for the GUI? It's not like there's a standard widget API MS could provide bindings for or anything.)
Then why not make the SFU framework available for download through Microsoft Update, like the
Still the same reason. In fact, I would suggest moreso. I'm sure more people go through Windows Update, even the manually accessed pages, than poke around on Windows CDs. (Especially as they aren't even included in most new computers.) Plus the fact that it's presented as an update rather than just something sitting around on the CD would suggest people would install it.
I don't really see the virtue in most people installing it. People who are tech savvy enough to want it can download it themselves (though it is admittedly not well known), or use Cygwin, which gives you a lot of the same benefits, and a wider selection of packages. (Though not case-sensitivity in the file system, and Cygwin apps seem to load slowly.)
Interns aren't tabula rasa, they're just inexperienced. What background did he have? Any IT schooling? If so, he was aware of what he was doing. All the persons in the chain of command are guilty, even the peons.
So what should he have done? Said "I'm not taking them" and risked getting fired?
He made a mistake, even a somewhat dumb one, but it's at least an understandable one. In his situation I would have taken the tapes too, though I would have kept them in the trunk until getting to my apartment, then taken them inside.
BTW, the post you're replying to was too harsh to be meant for you. Being wrong is fine; everyone's wrong sometimes. It's just that the poster I was replying to (who's currently modded troll) was sort of being an ass about being wrong.
;-)
I also tire of the anti-MS slant on Slashdot. I'll be the first to admit that Windows has flaws, and I have from time to time been fairly vocal about some stupidities of its design. That said, I'm one of the seemingly rare CS people who actually likes Windows. (I'm sure a lot of this is familiarity and the fact that I know how to do stuff on Windows, but I'm no stranger to Linux either.) It gets tiresome for people to complain that MS is wrong for every single thing that they do. So the "that sounds like bait and switch" or whatever bugged me a bit.
The reply I made directly to you was the one you were supposed to read.
Um, no. Bait and switch is advertising something then delivering another. MS did deliver it for the versions of Windows for which they advertised it for. And of course this ignores the fact that the OP was wrong about the bit rot bit, and in fact MS has *improved* the POSIX subsystem since they stopped shipping it with Windows, but I wouldn't expect the typical /. poster to actually know that, because it actually makes MS and Windows look a little less bad.
NT did include a POSIX system but that bit-rotted from lack of use and was removed I believe.
The POSIX subsystem is no longer included in Windows distributions, but you can still get it as a free download as part of Services for UNIX (SFU). (You'll also see mention of it as the Interix Subsystem and the Subsystem for UNIX-Based Applications (SUA).)
It is continually being maintained, and MS actually seems to have put an increased (albeit still small) push of it fairly recently. There is a fair suite of programs available for it, including GCC, Bash, automake/conf, SSH, etc., and it was supplanted to (supposedly) be POSIX.2 compliant. (When it shipped with Windows, it only supported POSIX.1.)
The big problem with it is that programs running under SUA can't access Windows API calls. This isn't surprising given the architecture of Windows, but it does mean that, for instance, you can't really have a GUI. I'm also not sure how complete the POSIX support actually is.
Basically I suspect it's a combination of they didn't want to put it on the CD and hence slightly encourage end users to install it (the did this with Windows 98 and TweakUI and Raymond Chen said it turned out to be a disaster for their tech support lines) and the CDs of XP being too full for it.
MS does use its own source control software. They don't use SourceSafe, they use their own proprietary and unpublished software.
I'm nearly positive this is true, but I'll check with a friend who works there later tonight.
In that case, I assert that you're the uncommon case. ;-)
I misremembered slightly what went wrong my latest point was an attempt to clarify.
The problem wasn't with slipstreaming the SATA driver, but it was caused by other messing around with the setup routine in nLite, specifically turning on some unattended features.
All I was trying to say was that when you start messing around with the setup, it's easy to make things go wrong. Maybe not so much if you're just slipstreaming a couple things, but there are so many checkboxes in nLite that do useful stuff that it's very easy to produce something that won't actually work right for what you want.
Oh yeah, I remember what happened in a little more detail now. At first I decided to not slipstream the SATA driver, but just SP2 + hotfixes and with semi-automatic installation (it fills out fields automatically but you still have to go through to accept them). The reason for this was because the driver is on floppy, and the computer I was doing this on didn't have a floppy drive, so I figured I'd just do the F6 thing at the start. The mix of unattended and floppy-drive loading was what caused the problem I linked to.
I still don't remember what the other problems were, but at one point I did wind up extracting then compressing the raw CAB files for some reason.
Yeah, unless you run into this problem
I still use a CRT too. I... am too cheap to spend $300 or more on a flat panel*, despite my current monitor approaching its last legs.
* After using 1600x1200 resolution for a few years, I ain't never going back. 1680 by whatever it is that widescreens sometimes are is about my limit in terms of how much smaller I'll accept. This basically means I need a 19", which start at ~$300. And if I got one anyway... I'd probably just put it next to this in a dual monitor setup.
Read the rest of this thread. r00t has a G4 Cube, so no onboard SATA and no room for a PCI card.
This adapter would probably actually work for him, unlike the PCI controller idea.
Whether it does or not depends on how your SATA controller presents itself. Does your motherboard have integrated SATA, or are you using an external controller?
If it does turn out to be an issue, you could always play around in a virtual machine. I very strongly doubt VM support for IDE is going anywhere for the foreseeable future.
This CAN take some effort though. I recently did this, slipstreaming (1) my SATA drivers, (2) Service Pack 2, and (3) all the hotfixes since SP2 into my XP CD, and I burned two or three coasters before getting it right. For instance, the first time I also tried to set up a semi-automatic install; but turns out this doesn't interact well with slipstreaming storage drivers like that. I forget what I screwed up after that.
All-in-all it took rather longer than it would have to just do it normally, and I coastered CDs in the process.
So should I remove my TV input card, my NIC, or my sound card to make room?
If you don't have a spare slot, yes, that's a problem.
And will companies continue to make SATA controllers after most PCI slot product lines have been replaced with PCI-e or USB 2.0 equivalents?
That's probably aways down the line. A quick survey shows PCI slots still outnumber PCI-e even on the highest-end mobos. (Though both seem to be in vanishingly small numbers.)
And how do I reinstall an operating system if the setup program doesn't recognize SATA?
If you're referring to Windows, that's what pressing F6 during the start of the textmode setup is for (I suspect you still have a floppy connected, though I could easily be wrong), or you can use nLite to slipstream your SATA drivers. Both solutions will work. If you're talking Linux, it shouldn't be a big issue to get a later revision that supports it.
Look, it's going to be inconvenient if you don't have SATA ports on your motherboard. (As I said in a couple other posts, I'm in that boat too. Though I did have a spare PCI slot.) But you can't reasonably expect companies to support legacy technology forever. It does cost them money to support the two standards, and I doubt they'll lose many sales because of this.
Floppy drives are still almost essential if you want to install Windows XP or earlier on a computer with a RAID or other controller card.
It's an unfortunate truth.
You can get a PCI controller card for $30 or so. I have two SATA drives, and most of my computer (including motherboard) is 5 years old, just as SATA was hitting the market, so I don't have integrated support.
It's not ideal, but it works plenty well enough.
There are still a lot of people out there with older computers you know. My mobo doesn't even have SATA ports, let alone no or poor IDE support.
(That said, I have a PCI SATA controller and two SATA drives, so...)
I read back over that link a couple days ago when I saw a reply further down, and I agree that it might be possible to construe it as diversion of services. When I read the page the first time I read it too quickly, and only looked at (a)(1)-(a)(4). And I *don't* see any way to argue that what they did violates anything in paragraph (a).
I don't know enough about the legal terminology or case law to speak to (b)'s applicability. I think it could go either way.
So I mostly retract my statement.
Oh c'mon. You're looking at the uncommon case. Do you really want to suggest that even a sizable minority of the sites you visit on a daily basis use HTTPS?
/. several times a day, I visit Fark a couple times a day, I visit a couple blogs a time or two a day, I visit CNN a couple times a day, I visit a couple other forums a couple times a day each, etc. NONE of these sites use SSL.
I visit my banking site a couple times a week. I shop online a couple times a month. I read email online more commonly, but not *that* commonly from a web browser.
By contrast, I visit
I generally agree with you, but I have a counterargument. (Unrelated to the issue of driving while on the phone, which is a whole other can of worms.)
My current phone has a weak '9' button. More than once I have dialed a number quickly and hit send before realizing "d'oh, it didn't register the 9". So in the case of my phone, the tactile feel of the buttons gives a false sense of security. Having to look at the screen anyway would help with that problem.