Although my mom made a big deal out of it, I've never really cared much when someone uses "me" where he should have used "I." On the other hand, for some reason (probably because I'm insane*), it is much more annoying when someone uses "I" where she should have used "me." A person is consciously making an extra effort to speak or write properly, and the effort is actually counterproductive. I am so incredibly lazy that I hate wasted effort, even when it is somebody else's wasted effort.:^)
The real rule (or close enough for me, since I'm not an English major) is that "I" is used for the subject and "me" is used as an object. But since most confusion comes in plural situations, the following rule of thumb usually is enough to get by:
Remove the other person/thing/entity from the sentence, and the correct word will usually become obvious.
In the case above, get rid of the boss for a second. "What I really need is a program that allows [my boss and] I to do such and such..."
"I need a program that allows I to do such and such." OR "I need a program that allows me to do such and such."
Sorry for the rant.
* I've come to terms with my insanity. Why can't you? --- If you must know, anal-retentive IS spelled with a hyphen.
That is a good attitude in my opinion. A bit more realistic than many I see on/.
I agree -- there are some inherent advantages to Open Source. And I am very glad that it exists, and wish I could do more to support it (I do some, but definitely a lot less than I benefit from it). On the other hand, I like to eat and pay my bills, so I am very glad that some people are willing to pay be to write software. I guess I get irritated and a bit defensive when people attack my livelihood without taking a moment to think about both sides of the issue.
Over time, I have come to believe that almost all issues have two sides -- two rational and valid points of view with many good arguments. To me, it means I should take a moment to try to see someone else's point of view before casting judgement. And as often as possible, I try to find a compromise -- a way to hold as much as possible of both sides in my head at the same time.
I figure there will always be competition between Open Source and proprietary. I think that is a good thing. I think there are some things that Microsoft does that I don't agree with, but so does every other company. Microsoft was simply more successful:). As far as Microsoft has abused its monopoly position, I have no problem with penalties to prevent the abuses in the future. I just hate it when everybody points at Microsoft as being the root of all evil for doing things that are normally considered simply a good business practice. The first thought of the SlashDot crowd seems to be "look how evil they are; they are so dead once Open Source takes over; yay!" I would prefer to see "why did they do that? how should we react? is this a positive move or stupid?"
Sorry about the situation the school is in. I'm sure it would be nice to have new hardware and software. But it has to get paid for somehow. Somebody has to pay programmers to write the stuff. I get lost right where you say that you don't expect it to be dirt cheap, but it shouldn't be as painful as it is...
I really apologize, because I know this will probably come off as pretty rude -- that isn't my intent. And I don't think it was your intent either. I'm not just responding to your message, but to a whole lot of messages in parallel to yours.
I'm afraid that the only way to not make it painful is to make it dirt cheap. I know schools don't have a whole lot of money, and it is pretty tough to keep them up to date. On the other hand, I spent a lot of time on an Apple IIe. My high-school senior thesis was written on a VAX terminal (in the Real World, 486's were king). Those were out of date, but somehow we got by.
Nobody is forcing you to upgrade from Windows 95. My mom still runs it and is happy with it -- it does what she needs it to do. For support, it probably has the biggest community of support of any OS every created, even Linux.
Microsoft has supported upgrades, security patches, and compatibility updates for Windows 95 long after it was officially end-of-lifed. When I was home last Christmas, I found a nice big wad of updates for my mom's computer, including security patches as well as browser and media player updates. On the other hand, some of the newest features (upgraded USB support, Media Player 9, Remote Desktop) aren't supported anymore.
Microsoft simply has a published policy that they don't support software forever. They will stop paying people specifically to maintain and support software after a certain point. This is generally understood before purchase -- if not the specific date of EOL, at least the general concept is understood by most people who buy it.
The software doesn't time-bomb. By the time the EOL date comes around, most of the critical bugs have patches or workarounds. NT4 (after six and a half service packs) ended up being one of the most stable and well-rounded products they've ever put out, so businesses happily continue using it. And serious problems seem to get support well after the EOL. Do we expect Microsoft to just make all new features we like available for free once we've paid our Microsoft Tax? Do we whine that the latest and greatest server products aren't available for free on NT4? Do you expect to get another Quarter Pounder next time you get hungry just because you paid for one yesterday?
Microsoft provides a certain level of support for a certain length of time after you purchase the product. If you want open source instead, Microsoft doesn't do anything to prevent you from using it. If you want more support, purchase an extended service contract or purchase the new OS. If you want the new features of the new OS, purchase the new OS. If you don't, then by all means, don't.
It took a lot of searching and a few false starts, but I finally got Linux going on my old laptop a few years ago. I guess I did it mostly for the challenge.
Specs:
386sx @ 16Mhz 5 Megs RAM (subtract a bit for BIOS shadowing...) 240MB HDD (half DOS, half Linux ext2) No PCMCIA, Ethernet, or IR ports. Currently boots MS-DOS/Win3.1 and then uses LoadLinux. Installed: Perl, GCC tool chain, vi, and just barely enough of everything else to get by.
I tried FreeBSD first -- that's what I normally run on my Unix boxes. However, while it can run on 5MB, it is a real challenge to get it installed with only 5MB -- the installer needs 8MB, and with no swap partition set up, it can only use RAM.
I came to the conclusion that the main problem with running a nice OS on not-so-nice hardware is getting a swap partition set up. Once Linux and FreeBSD have a little virtual memory to use, they can get by on just 4MB. But until the swap partition is mounted, everything has to squeeze into that 4MB, and it simply doesn't work.
I tried a few other distros before I finally found something that worked. It was called "ZipHam Linux." It was a derivative of Slackware running 2.0.38, and specialized for HAM radio enthusiasts. Once I had a swap partition set up, I could actually do stuff. I transferred packages via MS-DOS's InterLnk (parallel cable) and upgraded to the latest kernel I thought would work.
Recompiling the kernel on a 386sx with 4MB of RAM is an exercise in patience. I think it took about 23 hours. But it compiled! Yay. And booted.
About a year later, I graduated from college, got a better job, and bought a more reasonable laptop. As a result, the old one doesn't see much use anymore. But I still think it is pretty cool. And since it is actually the only Linux box in the house (1 FreeBSD box, and I run Linux under Bochs occasionally, but no other hardware dedicated to Linux), I sometimes fire it up just for kicks.
I've heard rumors of people getting Palm to run Linux, but I've never seen evidence of success. The Palm lacks certain architectural features, such as an MMU, that make it possible to write a truly powerful multitasking OS. I don't think you'll ever see Linux on the Palm, and if you do, I don't think it will be something you want on your own Palm Pilot.
On a better system, such as an IPAQ, the story can be completely different...
Windows -- both NTFS and FAT seem to delete a tree much more quickly than FreeBSD's native format (UFS, no? I never actually pay attention when I'm setting things up, and I haven't had to install my BSD box for a long time...). I do most of my dev work on NTFS-based systems, and cleaning/clobbering the source trees gives me plenty of opportunity to get a feel for how quickly it can delete.
Softupdates helped BSD, but not as much as I was hoping.
I don't play around with Linux nearly as much as BSD and Windows. But because of my experiences with BSD, I tried a few experiments on a Linux box I had to mess around with (I'm pretty sure it was running ext2) and the results were comparable with FreeBSD's.
Like I said, these are vague generalizations. I never took two samples on the same hardware, never used a stopwatch. But extracting and then deleting the PHP tarball and its corresponding tree is much faster on my Windows XP box than on my FreeBSD box. YMMV : )
Man, this is the longest I've ever had a thread go on SlashDot...
You are both right. XServers can be run in open or closed modes -- open means that they "serve" (obey the commands to open and manipulate windows) any client (application that wants to display a UI). Closed means they only accept connections from certain clients with certain credentials. Root still has power to do certain things to the XServer (root on the box on which the server is running) such as kill it, but root can't tell the server to hand over the keys...
However, that isn't the point the SecurityFocus poster was trying to make. He was saying that you (a nonprivileged user) launch an app that runs SUID as root, and that the app launches an XTerm window (also running as root) so that you can "configure" the app. Voila, the app has given you root, since you now have access to a root console. And it definitely wasn't XWindows' fault.
He was trying to say that the fact that a poorly written app can cause a vulnerability doesn't make the OS it runs on inherently less secure. I would hate to program for an OS that was so restrictive that even poorly written apps couldn't cause security problems. With power comes responsibility, eh?
Any well-written filesystem will push your video files around at about the same speed: the speed of your hard disk drive (assuming the files aren't too fragmented, which I suppose has some bearing on the filesystem). But in other tests, different filesystems make a huge difference.
After uncompressing and compiling a tarball, I am always given a lovely opportunity to ponder the mysteries of the universe as the rm -r latest-extracted-tarball command runs. For some reason, the delete of a tree seems to go really slowly on both FreeBSD and Linux, while the same operation seems to be a lot faster under Windows (no benchmarks here, just vague generalizations).
So this could make a real difference in real-life scenarios. The benchmarks listed are some of the more challenging performance hurdles for filesystem designers. If this doesn't hurt fragmentation rates, this sounds like a win-win.
Now you are confusing me (perhaps I am just easily confused : ) ).
Are you saying that Steve Ballmer tried to convince the judge that Linux is no competition? I can't think of a better way to shoot myself in the foot. If Linux is no competition, MS is a monopoly; if Linux is viable competition, MS goes free.
If Steve Ballmer had convinced the judge that Linux is a tough competitor, wouldn't that have been good for Microsoft? Microsoft is no longer a monopoly, as it has a tough competitor, so the lawsuit is dropped...
I think Steve is truly concerned about Linux eating into MS profits ($0 is a tough price to beat). And the judge thinks MS is still a monopoly even with Linux around.
Ok, you got me interested and I spent a bit more time looking this up. A few clarifications that I want to add right up front.
In the article, you state "Welcome, new admin [infoworld.com] quotes a security expert: 'Clearly this is a serious design flaw in Windows that violates basic security principles,...'" Ok, first, you say "Security Expert" without giving a name. That is a silly way to quote. Second, according to the original source in InfoWorld, it is a PRIVACY expert. There is a big difference.
Second, you state that "One writer said that the vulnerability has been known for years." Think about what this means: if the vuln. has been known for years, yet nobody makes anything of it and no huge exploits are performed, maybe it isn't a real vulnerability, eh?
Third, you have a link to "Considerable discussion," but your article indicates that either you haven't read all of it or you are purposely ignoring the explanations given there.
So here is the scoop: Microsoft allows you to write services, which are daemons which run in a different security context than the logged on user. Microsoft tells programmers that while nothing in the archtecture prevents them from doing so, services should not interact with the users. Programmers ignore Microsoft's recommendations, and their programs turn out to be vulnerabilities. Microsoft adds additional features to the OS to allow programmers to interact with the user in a non-risky way, as well as going through their own apps and correcting any mistakes that have been made by their own programmers (since nothing magical happens when Microsoft programmers are hired that make them instantly aware of all of Microsoft's recommendations). And Microsoft starts doing some parameter validation that helps avoid some of these exploits.
After some investigation into the two attacks mentioned by Chris (WM_TIMER and GetWindowsText), I have discovered the following behaviors on my own system. I haven't tried every combination, but this is how things appear to work on Windows XP:
Sending a WM_TIMER with an arbitrary address does nothing. Until an address has been registered by SetTimer(), that address will never be executed by the default message handler. I'm guessing that either Microsoft has added this protection recently or VirusScan was performing their own message handling and blindly called the address in the WM_TIMER.
Doing GetWindowsText with an arbitrary address does nothing. Chris mentions this as a vulnerability, but says nothing about having tried it out. I tried it, and it didn't do anything. I didn't have to think very hard to figure out why. The address you send to GetWindowsText is in YOUR OWN address space. So the address you overwrite is your OWN. Not a problem.
Some good stuff about these flaws:
Microsoft Systems Journal - Microsoft-sponsored journal that this on its own site, though with a bit less prejudice. The suggestion Matt mentions appears to have been implemented, since his sample does nothing.
Quote from the SecurityFocus discussion: To make an analogy in the Unix world, it would be like a deamon running as root opening an xterm on the users desktop to manage it. Nobody would say "X is broken" in this case - I think we'd all agree that the app is broken.
All-in-all, this is a dead horse. It simply appears that many programmers writing code for Windows don't worry too much about local security. And in many cases, they might be right in doing so -- most people don't care enough about priviledge escalation to pay extra for it. Those people can buy the cheap virus checker, while the people who do care can buy the one sold by a company who cares.
Perhaps we should take this offline. My email is listed.
I spent about 15 minutes trying to make programs crash using the WM_TIMER "vulnerability" on my computer and nothing happened. I sent a WM_TIMER with a random proc value to every window on my system. A few windows moved to the foreground/changed Z order, but that was all... I would have expected some "Access Violation" or system instability if the messages was going through unchecked. So either I don't understand the WM_TIMER problem, or Windows is doing something to protect against it. I will look into this further, but it appears that Windows is already doing at least some security checking on messages.
Microsoft's security division has always, always, always warned that services are vulnerability points, that they should not directly have a UI, and that developers need to be very careful when writing them, just like SUID apps. I'm sure that not everybody listens (just like programmers making SUID apps). It is very possible that some MS software breaks this rule (I know of some in the past, and it is possible that it isn't all fixed). But most current MS software follows the rule, which is why MMC (MS Management Console) exists -- it provides an indirect UI for services, where the UI is run in userspace, and the results are sent to the service via a pipe or socket. SQL server is another example -- a separate userspace app runs in the system tray that allows you to control SQL Server.
ProcExp shows a lot of system processes, but I don't think it shows windows, so ProcExp won't tell you anything about who is vulnerable.
The "Registry Vulnerability" is not really a problem, in my opinion. It certainly isn't perfect, but it isn't a source of vulnerability any more than/etc is under Linux. Each key has potentially separate permissions, just like each file in/etc. If a program gets the permissions wrong in the registry, it opens itself up for vulnerability just like a program that gets the permissions wrong in/etc.
One problem that Microsoft is up against for security issues is getting security right while keeping customers happy. Most people who buy Windows are very concerned about external security (remote hacks, logging in if you don't have any account, etc.) but don't care much about local security (a machine "User" becoming a machine "Admin"). In fact, most people running Windows run as Admin to get around all of that "annoying security stuff." In a way, this is a Bad Thing (programs don't get tested properly running as a normal user, so they actually require Admin rights to run properly; easier to shoot yourself in the foot), but in many circumstances, nobody cares. You can only trash your own box.
On the other hand, I have seem installations that have been locked down, and they seem to work well enough. People who really want to keep their computer secure (Local User can't make himself Admin) will have to alter the default install on NT4. I don't know about 2000, but for certain they will have to keep up with security patches. XP has a kind of Dr. Jeckyl and Mr. Hyde personality, where Dr. Jeckyl lets you do anything (consumer mentality) and Mr. Hyde is secure. You can successfully lock down XP if you want to.
Like I said, it is exactly like writing SUID programs for UNIX. I could write a similar column about Linux and BSD, and nobody would pay any attention to me. Those who really understand Windows programming know that what Chris is saying is nothing new and nothing alarming, which is why nobody has paid much attention to it.
Simply handle WM_TIMER messages and don't allow invalid addresses through to the default message handler and this won't happen. This is a problem with Windows' design, but definitely not an insurmountable one. It is just like any other IPC in any operating system -- don't trust commands that come from outside of the process.
As far as the window "vulnerability." The author of the expose neglects to mention that the vulerability only occurs if certain dangerous messages are allowed to pass to the default message handler untouched. While this may be a poor design, it is not an impossible-to-fix problem. I haven't checked, but I'm fairly certain that the system-level windows provided by the OS properly handle the potentially dangerous messages. That would be why he hasn't produced a demonstration of this.
That article the most dishonest, onesided essay I have read in a long time. By citing a reference to it, you have either admitted that you are gullible and uninformed enough to be convinced by someone spouting obvious logical fallacies and half-truths, or you are willing to endorse the use of such devices to further your own ends. There are plenty of decent complaints to make about Microsoft's behavior. Stooping to this level indicates that the writer is too lazy to come up with real things to say. Those who know how to recognize the problems with this article will come away from it with a lowered opinion of the authors and possibly, by association, the open source movement.
For example: the author states several times that XP is vulerable to certain attacks, but Linux/BSD/Unix is not. That's baloney. You can boot a Linux box from a floppy, edit the master password file on the hard disk, and reboot having taken over the box just as easily on Linux as you can on XP. Or maybe more easily -- I don't actually know how to find the Admin account's password entry under XP, but I know where it is on Linux and BSD.
Again: XP is vulerable to priviledge escalation, while Linux is not. We all know this is false. I get mail about every week about newly discovered ways in Linux and BSD to turn normal user priviledges into root. The patches come soon after. Same with XP.
And the guy claims that MS's assertions about security (if an intruder can run code on your box, it isn't your box anymore; if an intruder has physical access, it isn't your box anymore; if an intruder has a local account, it isn't your box anymore) show MS's idiot mindset about security. But any security professional knows that these are true: priviledge escalation from injected code proves you can't let an untrusted party run anything. One common attack was very famous a few years ago: Somebody on IRC says "type XYZ to see what happens!" and the newbie does it, unknowingly surrendering root to the stranger.
And the "serious flaw" mentioned was a flaw in the design of the virus console, not a flaw in Windows. The "message vulnerability" is almost exactly equivalent to an SUID vulnerability: programs that are accessible to the unpriviledged user but that need additional priviledges to do their job must be written with extreme caution. Microsoft's SDK explains what measures need to be taken, just as any competent Linux programmer would take special precautions when writing a utility that was going to run SUID. And there are ways to protect against every one of the "vulnerabilities" mentioned.
I kinda thought it was stupid, myself. But two differences between IBM's actions and MS's come to mind:
It appears to be a lot easier to clean up MS's plastic stickers (grab, stuff into trash bag, rinse, repeat) than to clean up drawings (wash, scrub -- some of the pictures are still there).
Second, I heard a rumor (unconfirmed) that MS had actually asked for and been granted a permit, but that it turned out to be invalid (the department issuing the permit didn't actually have authority to do so).
There isn't much new to add, but I'd better get my 2c in.
Yes, there are probably 100 clueless people for every clued person. The exact number depends on how much you have to know to "have a clue." Around here, it is called "passion." What do you do when a new technology comes out that is going to be the Next Big Thing(TM)? The answers range from "I was trained in C++ and I will stick with C++" to "ask the boss to send me in for training" to "grab a book and a laptop and try it out for myself."
Theoretically, the clued should have an advantage when it comes to getting and keeping jobs. When the company has to cut back, where will they cut? If your employers have kept any record of performance, your job is safe as long as there are clueless people to lay off first. Which is why those who got a bookstore degree (purchased a couple of Dummies books and got a web programming job 3 weeks later) are currently unemployed.
Well, that works well in theory, and it usually works out in the Real World too. But too often, the Clueless end up in charge. We do it to ourselves -- we hate politics, we'd rather be writing up a nifty hack than writing up specs and memos. So those who struggle with the code but seem to know a little bit about it wind up telling us what to do.
If you're lucky, you'll get someone who knows his/her limitations and who will work with you. Otherwise...
As far as this having to do with a College Education(TM), I think it is somewhat independent. A good geek doesn't need a teacher -- the stuff is always in books. But a teacher REALLY helps. After finishing a decent college curriculum, a student who had internal motivation to learn the stuff will have a well-rounded theoretical background. And if this student spent any time playing with stuff outside of class or doing summer internships, he/she should have no trouble getting a minimal level of experience.
At times, I have to evaluate other people in terms of potential value to my company. "Passion," or internal motivation to succeed, to learn, to solve problems, and to make a great product, is one of the biggest factors in my judgement.
Screw up my system upgrading from 2.(something) to 3.0 without reading the directions: yes.
Purchase the FreeBSD handbook at Comdex '97: yes
Run an Apache/PHP server on FreeBSD to serve a community web site: yes
Very proud that my old 486 box only crashed twice while serving said web site (once when the hard drive crashed, once when the water main in the host building broke): yes
Currently using it as my apartment's router, gateway, file server, and resident UNIX box (everybody needs a UNIX box in their apartment!): yes
Version currently in use: Somewhere around 4.5.STABLE
I apologize for feeding the trolls. I really should know better.
Correct me if I'm wrong, but I don't think priority inversions are an issue for Win(NT|XP). Consumer Windows (as well as Linux and most other general purpose OSes) runs a modified round-robin type scheduler. Priority inversions aren't an issue.
Windows CE has them, though...
Inversions happen on real-time OSes. In RT, the OS always selects the thread to schedule next out of the pool of eligible threads of priority X, where X is the highest priority that has any eligible threads. In other words, if any threads have a higher priority than you, as long as they aren't blocked, you'll never run.
Inversion is when a low-priority thread has a resource that a high-priority thread is waiting for. The low priority thread is bumped up in priority so that it can release the resource.
So a priority inversion problem is usually an application issue, not an OS issue -- the programmers didn't think very hard about the consequences of setting various priorities and acquiring various resources. And it is one of the reasons that programming real-time OS apps is tricky. Make a priority mistake on a general-purpose OS and your program might run a bit more slowly. Make a priority mistake on a real-time OS, and several threads will never run at all.
Of course, you were really referring to the fact that it crashed every 20 minutes, so this reply is completely pointless. Oh well...
Although most definitely off-topic, I'm glad this was posted. I've been wondering why FreeBSD has been having such a hard time, and this seems to give some decent reasons for it.
I still think BSD has some great things going for it, and in a few ways it still kicks Linux butt. But Linux is moving faster, so those areas may get smaller and smaller if FreeBSD doesn't get back in gear.
I've been using FreeBSD for 5 years now for various things. It was my desktop for a while, but now it is simply my preferred server platform. I don't know if there is any advantage to using it as opposed to Linux for my uses since I've never tried to replace it. But it has been great.
Anyway, I suppose this post is off-topic, too. But I hope to see both FreeBSD and Linux continuing long into the future. Long live the non-UNIX Unices!
I thought it was CS. The way I remember it (memory being a poor substitute for looking it up, but I'm lazy), there was a quick script thrown together to pull some of the floating point division tables from the 486's circuitry into the Pentium's circuitry. The tables in the two devices weren't exactly the same, so the script was supposed to account for the differences. Well, the script was flawed and copied some of the data to the wrong place, and nobody took the time to do a really detailed check on the resulting table -- it looked right, worked right in most cases, but in just a few it was a little bit off.
I think it was worse than that -- MSVC6 compiling with debug info enabled generates a (very long) warning for every template symbol generated, letting you know that the whole name for the symbol didn't fit into the debug info. This makes finding an important warning or error a major pain.
Took me forever to figure out how to disable the warning. It seems broken. But if you disable the warning before you include any headers, it usually works...
Maybe irrelevant to the average geek. But there is a utility I use at work to pack up a changelist from our source control system, a bit like using diff and patch. Well, to make it unpack the changes, you specify -u. Normally, it will refuse to unpack in a situation where you might be shooting yourself in the foot, but you can override it with -f (force). So the command to screw yourself over was
Slashdot Mirror
Sorry, pet peeve.
:^)
Although my mom made a big deal out of it, I've never really cared much when someone uses "me" where he should have used "I." On the other hand, for some reason (probably because I'm insane*), it is much more annoying when someone uses "I" where she should have used "me." A person is consciously making an extra effort to speak or write properly, and the effort is actually counterproductive. I am so incredibly lazy that I hate wasted effort, even when it is somebody else's wasted effort.
The real rule (or close enough for me, since I'm not an English major) is that "I" is used for the subject and "me" is used as an object. But since most confusion comes in plural situations, the following rule of thumb usually is enough to get by:
Remove the other person/thing/entity from the sentence, and the correct word will usually become obvious.
In the case above, get rid of the boss for a second. "What I really need is a program that allows [my boss and] I to do such and such..."
"I need a program that allows I to do such and such."
OR
"I need a program that allows me to do such and such."
Sorry for the rant.
* I've come to terms with my insanity. Why can't you?
---
If you must know, anal-retentive IS spelled with a hyphen.
That is a good attitude in my opinion. A bit more realistic than many I see on /.
:). As far as Microsoft has abused its monopoly position, I have no problem with penalties to prevent the abuses in the future. I just hate it when everybody points at Microsoft as being the root of all evil for doing things that are normally considered simply a good business practice. The first thought of the SlashDot crowd seems to be "look how evil they are; they are so dead once Open Source takes over; yay!" I would prefer to see "why did they do that? how should we react? is this a positive move or stupid?"
I agree -- there are some inherent advantages to Open Source. And I am very glad that it exists, and wish I could do more to support it (I do some, but definitely a lot less than I benefit from it). On the other hand, I like to eat and pay my bills, so I am very glad that some people are willing to pay be to write software. I guess I get irritated and a bit defensive when people attack my livelihood without taking a moment to think about both sides of the issue.
Over time, I have come to believe that almost all issues have two sides -- two rational and valid points of view with many good arguments. To me, it means I should take a moment to try to see someone else's point of view before casting judgement. And as often as possible, I try to find a compromise -- a way to hold as much as possible of both sides in my head at the same time.
I figure there will always be competition between Open Source and proprietary. I think that is a good thing. I think there are some things that Microsoft does that I don't agree with, but so does every other company. Microsoft was simply more successful
Sorry about the situation the school is in. I'm sure it would be nice to have new hardware and software. But it has to get paid for somehow. Somebody has to pay programmers to write the stuff. I get lost right where you say that you don't expect it to be dirt cheap, but it shouldn't be as painful as it is...
I really apologize, because I know this will probably come off as pretty rude -- that isn't my intent. And I don't think it was your intent either. I'm not just responding to your message, but to a whole lot of messages in parallel to yours.
I'm afraid that the only way to not make it painful is to make it dirt cheap. I know schools don't have a whole lot of money, and it is pretty tough to keep them up to date. On the other hand, I spent a lot of time on an Apple IIe. My high-school senior thesis was written on a VAX terminal (in the Real World, 486's were king). Those were out of date, but somehow we got by.
Nobody is forcing you to upgrade from Windows 95. My mom still runs it and is happy with it -- it does what she needs it to do. For support, it probably has the biggest community of support of any OS every created, even Linux.
Microsoft has supported upgrades, security patches, and compatibility updates for Windows 95 long after it was officially end-of-lifed. When I was home last Christmas, I found a nice big wad of updates for my mom's computer, including security patches as well as browser and media player updates. On the other hand, some of the newest features (upgraded USB support, Media Player 9, Remote Desktop) aren't supported anymore.
Microsoft simply has a published policy that they don't support software forever. They will stop paying people specifically to maintain and support software after a certain point. This is generally understood before purchase -- if not the specific date of EOL, at least the general concept is understood by most people who buy it.
The software doesn't time-bomb. By the time the EOL date comes around, most of the critical bugs have patches or workarounds. NT4 (after six and a half service packs) ended up being one of the most stable and well-rounded products they've ever put out, so businesses happily continue using it. And serious problems seem to get support well after the EOL. Do we expect Microsoft to just make all new features we like available for free once we've paid our Microsoft Tax? Do we whine that the latest and greatest server products aren't available for free on NT4? Do you expect to get another Quarter Pounder next time you get hungry just because you paid for one yesterday?
Microsoft provides a certain level of support for a certain length of time after you purchase the product. If you want open source instead, Microsoft doesn't do anything to prevent you from using it. If you want more support, purchase an extended service contract or purchase the new OS. If you want the new features of the new OS, purchase the new OS. If you don't, then by all means, don't.
Just quit whining.
It took a lot of searching and a few false starts, but I finally got Linux going on my old laptop a few years ago. I guess I did it mostly for the challenge.
Specs:
386sx @ 16Mhz
5 Megs RAM (subtract a bit for BIOS shadowing...)
240MB HDD (half DOS, half Linux ext2)
No PCMCIA, Ethernet, or IR ports.
Currently boots MS-DOS/Win3.1 and then uses LoadLinux.
Installed: Perl, GCC tool chain, vi, and just barely enough of everything else to get by.
I tried FreeBSD first -- that's what I normally run on my Unix boxes. However, while it can run on 5MB, it is a real challenge to get it installed with only 5MB -- the installer needs 8MB, and with no swap partition set up, it can only use RAM.
I came to the conclusion that the main problem with running a nice OS on not-so-nice hardware is getting a swap partition set up. Once Linux and FreeBSD have a little virtual memory to use, they can get by on just 4MB. But until the swap partition is mounted, everything has to squeeze into that 4MB, and it simply doesn't work.
I tried a few other distros before I finally found something that worked. It was called "ZipHam Linux." It was a derivative of Slackware running 2.0.38, and specialized for HAM radio enthusiasts. Once I had a swap partition set up, I could actually do stuff. I transferred packages via MS-DOS's InterLnk (parallel cable) and upgraded to the latest kernel I thought would work.
Recompiling the kernel on a 386sx with 4MB of RAM is an exercise in patience. I think it took about 23 hours. But it compiled! Yay. And booted.
About a year later, I graduated from college, got a better job, and bought a more reasonable laptop. As a result, the old one doesn't see much use anymore. But I still think it is pretty cool. And since it is actually the only Linux box in the house (1 FreeBSD box, and I run Linux under Bochs occasionally, but no other hardware dedicated to Linux), I sometimes fire it up just for kicks.
I've heard rumors of people getting Palm to run Linux, but I've never seen evidence of success. The Palm lacks certain architectural features, such as an MMU, that make it possible to write a truly powerful multitasking OS. I don't think you'll ever see Linux on the Palm, and if you do, I don't think it will be something you want on your own Palm Pilot.
On a better system, such as an IPAQ, the story can be completely different...
How long have you been waiting to post this? : )
Surprisingly well written for an offtopic troll. If you weren't an anonymous coward, I would have modded you up!
(You see, I believe that not all offtopic trolls are bad.)
Windows -- both NTFS and FAT seem to delete a tree much more quickly than FreeBSD's native format (UFS, no? I never actually pay attention when I'm setting things up, and I haven't had to install my BSD box for a long time...). I do most of my dev work on NTFS-based systems, and cleaning/clobbering the source trees gives me plenty of opportunity to get a feel for how quickly it can delete.
Softupdates helped BSD, but not as much as I was hoping.
I don't play around with Linux nearly as much as BSD and Windows. But because of my experiences with BSD, I tried a few experiments on a Linux box I had to mess around with (I'm pretty sure it was running ext2) and the results were comparable with FreeBSD's.
Like I said, these are vague generalizations. I never took two samples on the same hardware, never used a stopwatch. But extracting and then deleting the PHP tarball and its corresponding tree is much faster on my Windows XP box than on my FreeBSD box. YMMV : )
Man, this is the longest I've ever had a thread go on SlashDot...
You are both right. XServers can be run in open or closed modes -- open means that they "serve" (obey the commands to open and manipulate windows) any client (application that wants to display a UI). Closed means they only accept connections from certain clients with certain credentials. Root still has power to do certain things to the XServer (root on the box on which the server is running) such as kill it, but root can't tell the server to hand over the keys...
However, that isn't the point the SecurityFocus poster was trying to make. He was saying that you (a nonprivileged user) launch an app that runs SUID as root, and that the app launches an XTerm window (also running as root) so that you can "configure" the app. Voila, the app has given you root, since you now have access to a root console. And it definitely wasn't XWindows' fault.
He was trying to say that the fact that a poorly written app can cause a vulnerability doesn't make the OS it runs on inherently less secure. I would hate to program for an OS that was so restrictive that even poorly written apps couldn't cause security problems. With power comes responsibility, eh?
Any well-written filesystem will push your video files around at about the same speed: the speed of your hard disk drive (assuming the files aren't too fragmented, which I suppose has some bearing on the filesystem). But in other tests, different filesystems make a huge difference.
After uncompressing and compiling a tarball, I am always given a lovely opportunity to ponder the mysteries of the universe as the rm -r latest-extracted-tarball command runs. For some reason, the delete of a tree seems to go really slowly on both FreeBSD and Linux, while the same operation seems to be a lot faster under Windows (no benchmarks here, just vague generalizations).
So this could make a real difference in real-life scenarios. The benchmarks listed are some of the more challenging performance hurdles for filesystem designers. If this doesn't hurt fragmentation rates, this sounds like a win-win.
Now you are confusing me (perhaps I am just easily confused : ) ).
Are you saying that Steve Ballmer tried to convince the judge that Linux is no competition? I can't think of a better way to shoot myself in the foot. If Linux is no competition, MS is a monopoly; if Linux is viable competition, MS goes free.
If Steve Ballmer had convinced the judge that Linux is a tough competitor, wouldn't that have been good for Microsoft? Microsoft is no longer a monopoly, as it has a tough competitor, so the lawsuit is dropped...
I think Steve is truly concerned about Linux eating into MS profits ($0 is a tough price to beat). And the judge thinks MS is still a monopoly even with Linux around.
In the article, you state "Welcome, new admin [infoworld.com] quotes a security expert: 'Clearly this is a serious design flaw in Windows that violates basic security principles,
Second, you state that "One writer said that the vulnerability has been known for years." Think about what this means: if the vuln. has been known for years, yet nobody makes anything of it and no huge exploits are performed, maybe it isn't a real vulnerability, eh?
Third, you have a link to "Considerable discussion," but your article indicates that either you haven't read all of it or you are purposely ignoring the explanations given there.
So here is the scoop: Microsoft allows you to write services, which are daemons which run in a different security context than the logged on user. Microsoft tells programmers that while nothing in the archtecture prevents them from doing so, services should not interact with the users. Programmers ignore Microsoft's recommendations, and their programs turn out to be vulnerabilities. Microsoft adds additional features to the OS to allow programmers to interact with the user in a non-risky way, as well as going through their own apps and correcting any mistakes that have been made by their own programmers (since nothing magical happens when Microsoft programmers are hired that make them instantly aware of all of Microsoft's recommendations). And Microsoft starts doing some parameter validation that helps avoid some of these exploits.
After some investigation into the two attacks mentioned by Chris (WM_TIMER and GetWindowsText), I have discovered the following behaviors on my own system. I haven't tried every combination, but this is how things appear to work on Windows XP:
Sending a WM_TIMER with an arbitrary address does nothing. Until an address has been registered by SetTimer(), that address will never be executed by the default message handler. I'm guessing that either Microsoft has added this protection recently or VirusScan was performing their own message handling and blindly called the address in the WM_TIMER.
Doing GetWindowsText with an arbitrary address does nothing. Chris mentions this as a vulnerability, but says nothing about having tried it out. I tried it, and it didn't do anything. I didn't have to think very hard to figure out why. The address you send to GetWindowsText is in YOUR OWN address space. So the address you overwrite is your OWN. Not a problem.
Some good stuff about these flaws:
All-in-all, this is a dead horse. It simply appears that many programmers writing code for Windows don't worry too much about local security. And in many cases, they might be right in doing so -- most people don't care enough about priviledge escalation to pay extra for it. Those people can buy the cheap virus checker, while the people who do care can buy the one sold by a company who cares.
Perhaps we should take this offline. My email is listed.
/etc is under Linux. Each key has potentially separate permissions, just like each file in /etc. If a program gets the permissions wrong in the registry, it opens itself up for vulnerability just like a program that gets the permissions wrong in /etc.
I spent about 15 minutes trying to make programs crash using the WM_TIMER "vulnerability" on my computer and nothing happened. I sent a WM_TIMER with a random proc value to every window on my system. A few windows moved to the foreground/changed Z order, but that was all... I would have expected some "Access Violation" or system instability if the messages was going through unchecked. So either I don't understand the WM_TIMER problem, or Windows is doing something to protect against it. I will look into this further, but it appears that Windows is already doing at least some security checking on messages.
Microsoft's security division has always, always, always warned that services are vulnerability points, that they should not directly have a UI, and that developers need to be very careful when writing them, just like SUID apps. I'm sure that not everybody listens (just like programmers making SUID apps). It is very possible that some MS software breaks this rule (I know of some in the past, and it is possible that it isn't all fixed). But most current MS software follows the rule, which is why MMC (MS Management Console) exists -- it provides an indirect UI for services, where the UI is run in userspace, and the results are sent to the service via a pipe or socket. SQL server is another example -- a separate userspace app runs in the system tray that allows you to control SQL Server.
ProcExp shows a lot of system processes, but I don't think it shows windows, so ProcExp won't tell you anything about who is vulnerable.
The "Registry Vulnerability" is not really a problem, in my opinion. It certainly isn't perfect, but it isn't a source of vulnerability any more than
One problem that Microsoft is up against for security issues is getting security right while keeping customers happy. Most people who buy Windows are very concerned about external security (remote hacks, logging in if you don't have any account, etc.) but don't care much about local security (a machine "User" becoming a machine "Admin"). In fact, most people running Windows run as Admin to get around all of that "annoying security stuff." In a way, this is a Bad Thing (programs don't get tested properly running as a normal user, so they actually require Admin rights to run properly; easier to shoot yourself in the foot), but in many circumstances, nobody cares. You can only trash your own box.
On the other hand, I have seem installations that have been locked down, and they seem to work well enough. People who really want to keep their computer secure (Local User can't make himself Admin) will have to alter the default install on NT4. I don't know about 2000, but for certain they will have to keep up with security patches. XP has a kind of Dr. Jeckyl and Mr. Hyde personality, where Dr. Jeckyl lets you do anything (consumer mentality) and Mr. Hyde is secure. You can successfully lock down XP if you want to.
If that is what Christ says then Chris is wrong.
Like I said, it is exactly like writing SUID programs for UNIX. I could write a similar column about Linux and BSD, and nobody would pay any attention to me. Those who really understand Windows programming know that what Chris is saying is nothing new and nothing alarming, which is why nobody has paid much attention to it.
Simply handle WM_TIMER messages and don't allow invalid addresses through to the default message handler and this won't happen. This is a problem with Windows' design, but definitely not an insurmountable one. It is just like any other IPC in any operating system -- don't trust commands that come from outside of the process.
I'm pretty sure I got the latest version.
As far as the window "vulnerability." The author of the expose neglects to mention that the vulerability only occurs if certain dangerous messages are allowed to pass to the default message handler untouched. While this may be a poor design, it is not an impossible-to-fix problem. I haven't checked, but I'm fairly certain that the system-level windows provided by the OS properly handle the potentially dangerous messages. That would be why he hasn't produced a demonstration of this.
That article the most dishonest, onesided essay I have read in a long time. By citing a reference to it, you have either admitted that you are gullible and uninformed enough to be convinced by someone spouting obvious logical fallacies and half-truths, or you are willing to endorse the use of such devices to further your own ends. There are plenty of decent complaints to make about Microsoft's behavior. Stooping to this level indicates that the writer is too lazy to come up with real things to say. Those who know how to recognize the problems with this article will come away from it with a lowered opinion of the authors and possibly, by association, the open source movement.
For example: the author states several times that XP is vulerable to certain attacks, but Linux/BSD/Unix is not. That's baloney. You can boot a Linux box from a floppy, edit the master password file on the hard disk, and reboot having taken over the box just as easily on Linux as you can on XP. Or maybe more easily -- I don't actually know how to find the Admin account's password entry under XP, but I know where it is on Linux and BSD.
Again: XP is vulerable to priviledge escalation, while Linux is not. We all know this is false. I get mail about every week about newly discovered ways in Linux and BSD to turn normal user priviledges into root. The patches come soon after. Same with XP.
And the guy claims that MS's assertions about security (if an intruder can run code on your box, it isn't your box anymore; if an intruder has physical access, it isn't your box anymore; if an intruder has a local account, it isn't your box anymore) show MS's idiot mindset about security. But any security professional knows that these are true: priviledge escalation from injected code proves you can't let an untrusted party run anything. One common attack was very famous a few years ago: Somebody on IRC says "type XYZ to see what happens!" and the newbie does it, unknowingly surrendering root to the stranger.
And the "serious flaw" mentioned was a flaw in the design of the virus console, not a flaw in Windows. The "message vulnerability" is almost exactly equivalent to an SUID vulnerability: programs that are accessible to the unpriviledged user but that need additional priviledges to do their job must be written with extreme caution. Microsoft's SDK explains what measures need to be taken, just as any competent Linux programmer would take special precautions when writing a utility that was going to run SUID. And there are ways to protect against every one of the "vulnerabilities" mentioned.
I kinda thought it was stupid, myself. But two differences between IBM's actions and MS's come to mind:
It appears to be a lot easier to clean up MS's plastic stickers (grab, stuff into trash bag, rinse, repeat) than to clean up drawings (wash, scrub -- some of the pictures are still there).
Second, I heard a rumor (unconfirmed) that MS had actually asked for and been granted a permit, but that it turned out to be invalid (the department issuing the permit didn't actually have authority to do so).
There isn't much new to add, but I'd better get my 2c in.
Yes, there are probably 100 clueless people for every clued person. The exact number depends on how much you have to know to "have a clue." Around here, it is called "passion." What do you do when a new technology comes out that is going to be the Next Big Thing(TM)? The answers range from "I was trained in C++ and I will stick with C++" to "ask the boss to send me in for training" to "grab a book and a laptop and try it out for myself."
Theoretically, the clued should have an advantage when it comes to getting and keeping jobs. When the company has to cut back, where will they cut? If your employers have kept any record of performance, your job is safe as long as there are clueless people to lay off first. Which is why those who got a bookstore degree (purchased a couple of Dummies books and got a web programming job 3 weeks later) are currently unemployed.
Well, that works well in theory, and it usually works out in the Real World too. But too often, the Clueless end up in charge. We do it to ourselves -- we hate politics, we'd rather be writing up a nifty hack than writing up specs and memos. So those who struggle with the code but seem to know a little bit about it wind up telling us what to do.
If you're lucky, you'll get someone who knows his/her limitations and who will work with you. Otherwise...
As far as this having to do with a College Education(TM), I think it is somewhat independent. A good geek doesn't need a teacher -- the stuff is always in books. But a teacher REALLY helps. After finishing a decent college curriculum, a student who had internal motivation to learn the stuff will have a well-rounded theoretical background. And if this student spent any time playing with stuff outside of class or doing summer internships, he/she should have no trouble getting a minimal level of experience.
At times, I have to evaluate other people in terms of potential value to my company. "Passion," or internal motivation to succeed, to learn, to solve problems, and to make a great product, is one of the biggest factors in my judgement.
- Ever touched a system running BSD: yes.
- Installed a system running BSD: yes.
- Screw up my system upgrading from 2.(something) to 3.0 without reading the directions: yes.
- Purchase the FreeBSD handbook at Comdex '97: yes
- Run an Apache/PHP server on FreeBSD to serve a community web site: yes
- Very proud that my old 486 box only crashed twice while serving said web site (once when the hard drive crashed, once when the water main in the host building broke): yes
- Currently using it as my apartment's router, gateway, file server, and resident UNIX box (everybody needs a UNIX box in their apartment!): yes
- Version currently in use: Somewhere around 4.5.STABLE
I apologize for feeding the trolls. I really should know better.Correct me if I'm wrong, but I don't think priority inversions are an issue for Win(NT|XP). Consumer Windows (as well as Linux and most other general purpose OSes) runs a modified round-robin type scheduler. Priority inversions aren't an issue.
Windows CE has them, though...
Inversions happen on real-time OSes. In RT, the OS always selects the thread to schedule next out of the pool of eligible threads of priority X, where X is the highest priority that has any eligible threads. In other words, if any threads have a higher priority than you, as long as they aren't blocked, you'll never run.
Inversion is when a low-priority thread has a resource that a high-priority thread is waiting for. The low priority thread is bumped up in priority so that it can release the resource.
So a priority inversion problem is usually an application issue, not an OS issue -- the programmers didn't think very hard about the consequences of setting various priorities and acquiring various resources. And it is one of the reasons that programming real-time OS apps is tricky. Make a priority mistake on a general-purpose OS and your program might run a bit more slowly. Make a priority mistake on a real-time OS, and several threads will never run at all.
Of course, you were really referring to the fact that it crashed every 20 minutes, so this reply is completely pointless. Oh well...
Just to draw attention to unimportant detail :)
What significance? Yes, it would confuse me for a second because it almost looks like a number with significance, but it isn't, really.
Perhaps you mean -32768. Assuming a 16 bit short, (short)0x8000==-32768 and (unsigned short)0xFFFF==65535.
To get -65535, you have to have more than 16 bits - (INT32)0xFFFF0000==-65535.
Although most definitely off-topic, I'm glad this was posted. I've been wondering why FreeBSD has been having such a hard time, and this seems to give some decent reasons for it.
I still think BSD has some great things going for it, and in a few ways it still kicks Linux butt. But Linux is moving faster, so those areas may get smaller and smaller if FreeBSD doesn't get back in gear.
I've been using FreeBSD for 5 years now for various things. It was my desktop for a while, but now it is simply my preferred server platform. I don't know if there is any advantage to using it as opposed to Linux for my uses since I've never tried to replace it. But it has been great.
Anyway, I suppose this post is off-topic, too. But I hope to see both FreeBSD and Linux continuing long into the future. Long live the non-UNIX Unices!
I thought it was CS. The way I remember it (memory being a poor substitute for looking it up, but I'm lazy), there was a quick script thrown together to pull some of the floating point division tables from the 486's circuitry into the Pentium's circuitry. The tables in the two devices weren't exactly the same, so the script was supposed to account for the differences. Well, the script was flawed and copied some of the data to the wrong place, and nobody took the time to do a really detailed check on the resulting table -- it looked right, worked right in most cases, but in just a few it was a little bit off.
Got it -- good point.
(La de dah, waiting to avoid lameness...)
I think it was worse than that -- MSVC6 compiling with debug info enabled generates a (very long) warning for every template symbol generated, letting you know that the whole name for the symbol didn't fit into the debug info. This makes finding an important warning or error a major pain.
Took me forever to figure out how to disable the warning. It seems broken. But if you disable the warning before you include any headers, it usually works...
Maybe irrelevant to the average geek. But there is a utility I use at work to pack up a changelist from our source control system, a bit like using diff and patch. Well, to make it unpack the changes, you specify -u. Normally, it will refuse to unpack in a situation where you might be shooting yourself in the foot, but you can override it with -f (force). So the command to screw yourself over was
bbpack -f -u