Well, if someone 'sane' in the bldg had been packing a weapon, they might have ended this asshole's rampage a bit earlier....
Or found their weapon stolen and had been used to kill even more people. Or been outgunned in a hall shootout in the same manner as the armed guard at Columbine.
This is breaking news, can we please all put down our politics until the story becomes more coherent?
Could you elaborate on this? When I used to write networking code I never "queried" to figure out what kind of protocol was installed.
IPv6 certainly did cause some disruption, but that was all caused by needing to support both AF_INET and AF_INET6 addresses. Once you switched from inet_addr() to inet_pton() and made sure to check sockaddr_in.sa_family_t, the rest of the code was pretty much the same.
He may have had a 49g+ which had crappy keyboards, but there has been NO reported breakage of the 50G keyboard. I've had one over a year before they were launched (beta testing) and mine is still going strong. It is used over 4 hours a day.
I'm glad yours is OK. My friends, however, is not. Believe whatever you want.
Between a good friend and I we have about 6 HP48 calculators, including (drum roll) one of the very last 48GX's ever made STILL UNOPENED in package. I've got two GXs and one G, he's got 2 GX's and an SX. He's also got a 50. The 50 lasted about six weeks into his electrical engineering coursework before the keys began breaking -- and it had already been replaced once under warranty. My main 48GX has survived the worst of a chemical engineering undergrad and still going strong.
The moral: the 50 is really nice, but is too flimsy to handle the real-world workload.
Looks like I've struck a nerve, here. Interesting...if what I'm saying is, "bullshit," then why bother getting so upset about it?
Oh, so after you insult every developer who doesn't use the BSD license (which as I noted is a pretty pointless license), now you want to backtrack and take the high road to impartiality. As you say, "interesting."
I suppose I was mistaken afterall, after seeing how nice and friendly you are now. You didn't REALLY mean to say outright that I and the several good developers I have worked with in the past only care about writing Microsoft knockoffs in our spare time, or that we are idiots who don't really understand the concept of community software. You must have been saying something else.
What a crock of shit! Only BSD developers love to code? Linux is driven by a hatred of Microsoft? Fuck you too.
You look in my posting history, you'll see I use GPL for a lot of my work. That's not because I fear Microsoft, it's because I want to get paid if a company wants to take my code. But I code anyway because I like to, I've got specific needs that aren't met by what I find out there so I start my own projects to get there.
But then I get to code that I don't care about getting paid for, or I want to use both inside and outside of work. That stuff is a gift: I license it public domain. I see no point in licensing code BSD when public domain is already well understood and out there. If you want credit, just make sure you have a web site and stick your project on your resume.
There are a lot of things that the FSF have done that I continue to feel outraged about, but polluting the original motivation behind open source has to be one of the very worst.
That's pretty rich, what are you smoking so we can get some?
The motivation has ALWAYS been about writing code. For some developers, they want to get paid too so they use GPL; others don't care or don't need to get paid, so they use BSD; still others use one of the many other existing OSS licenses for their own reasons.
You want to be pissed at FSF, fine, go write a compiler suite while you're at it. You want to be pissed at the thousands of developers who (shock!) love to write code but don't already agree with you, then too fucking bad for you. You want to argue about some ideological license purity bullshit? Then why the fuck are you using the BSD license instead of just leaving it in public domain?
Don't like my profanity? Tough shit. You say profane ideas, you get a profane response.
4) Copy the base build package selections over: scp master:selections ~ . ~10 seconds.
5) Select the base build: dpkg --set-selections < selections . ~10 seconds.
6) Run dselect to install everything. Answer the questions as appropriate. ~2 minutes.
7) Let dselect do the actual installation. ~30 minutes.
8) Copy over/etc/hosts, modify/etc/fstab to mount the NFS shares, modify/etc/group,/etc/passwd, and/etc/shadow to use NIS. ~2 minutes.
9) Take the box to whatever room it belongs in.
10) DONE.
At the end of this procedure the box has been configured from bare metal to the standard build which includes quite a bit of application and development software, NIS and NFS are there so users have full access to their existing setups, and everything is up-to-date with security patches.
Granted, I don't do Windows support, but the closest I have ever come to this in Windows is using either Partition Magic or Ghost to get a drive re-imaged, and even then I have to bypass the Microsoft installer, Windows update, and dozens of application software installers that can each take 10-30 minutes to get through. Or in the case of Visual Studio.NET, almost 3 hours.
I'd like to know the story behind those two products. How could the same company produce two products with such disparate quality?
This is what I heard while working for one of the WebSphere applications group. Eclipse was developed by a company IBM had acquired whose name escapes me -- started with an O I think. Anyway, even though they were IBM, they weren't "IBM": they used completely different tools for their work, had access to most of IBM's codebase but provided almost none of their own back to the rest of the company -- much like the Lotus group. The people in WebSphere were exasperated at them because they delayed delivery so long to develop SWT when (it was assumed) they could have just modified Swing to achieve the same effect. Finally, Eclipse was first and foremost meant to be a direct competitor to Visual Studio and cost a lot of money. After quite a few years (I got the impression 5-10 years from the dev talking to me), IBM had sunk about $30 million into Eclipse and still had no shipping products.
It was released as OSS when it became obvious that IBM could not possibly take on Visual Studio in the Windows environment: Eclipse was too slow, too big, and too feature-poor compared even to VS '97. Of course, IBM didn't know that VS.Net was going to be much bigger, much slower, and take all its new feature cues from Visual Basic. Regardless, IBM correctly realized that after the initial bug-fixing and stability issues were addressed, they could use the OSS base to build their ultimate dev platform: WSAD. (However, as of 2003, the devs I knew within IBM who had both Eclipse/WSAD and NetBeans preferred NetBeans.)
Visual Age was originally from the Smalltalk product line. (I knew a few developers who had once been on that team, unfortunately their skills didn't translate very well into Java for their later work.) VAJava was meant to go up against Visual J++, Symantec cafe-something-or-other, and the Borland Java. Back in 1999 it was a reasonable competitor in that field (remember that was back when Java IDEs were very new and crash-prone). About that time were the first serious Java desktop applications, and people began to see that Java was too slow on that generation of hardware, hence VAJava languished until Eclipse delivered the death blow.
Since you asked about how IBM can be so schizophrenic, here is my take on the bigger picture. The IBMers who grew up on the mainframe and AIX can write some seriously good code with lots of excellent diagnostics. (Go read the DB2 message reference sometime.) However, IBM's ultimate problem is its desire within management to create "solutions" for businesspeople. So they tend to take products that work well in their respective domains and "IBM-ize" them into things unlike anything else in the market. Hence AIX has a C++ compiler that creates highly optimized code but is even worse to deal with than VC++. AIX is also so unique that almost no one outside IBM is qualified to work on it, yet it is a fantastic operating system and combined with DB2 makes the best datastore I have ever seen. When they buy products from small companies (like the original WebSphere server) they alter the company culture so much that all the good talent leaves and then they spend two product lifecycles just developing inhouse skill to essentially re-create the product from scratch. OTOH, when they buy companies too large to do that with (like Lotus) they end up with these rogue units producing code that barely works at all within the rest of the IBM landscape.
As far as their product lines go, you can tell easily which group makes what. DB2 comes out of the Server Group, who mostly do big iron hardware, hence DB2 rocks. WebSphere comes out of the Software Group, which is mostly Windows weenies who STILL don't understand that case-sensitive filesystems exist and not everything written in Java needs to run as root. Code from IGS can't be installed without a consultant because they haven't learned how to use 'make' from Server Group. Code you get from IBM Research is lucky to compile at all.
The biggest problem isn't about just the anti-tivoization problems or what ever. It's the fact that the new rules are not well written, they are based on simple problems that the FSF has had with GPL v2.
Welcome to the real world. Go look up your local government's property code for an astonishingly large collection of laws designed to prevent people from being assholes with rented property. It's almost as if there is always some significant part of the population whose sole aim in life is to fuck things up for everyone else.
If Linus blesses a fork, I'd say it's a pretty safe bet that his is going to trounce the FSF one.
If this was 1996 I'd agree with you. Now, not so much. The other kernel developers have lots of code in there and reasons of their own to maintain compatibility with glibc at any version. Remember how many people needed to use -mm and -ac versions of the kernel at different times? Those are forks maintained by other high-ranking kernel developers.
If you are Tivo it matters a great deal. LGPL stipulates that the library is still replaceable by the end user and hence the DRM lockdown can be trivially circumvented.
Perhaps you were thinking about a commercial app that can link to glibc but keep its code closed.
Or you could just rationally and objectively think about the relative difficulties of coding up a windows app that masquerades as a login screen vs replacing system level DLLs as an unprivileged user for more than a minute or two.
"Rationally and objectively" usually is a euphemism for "you need to think like me"...
Crackers don't need to know how to code. People who know how to code have already written all the utilities they need. Rootkits: done. Network backdoors: done. Network scanning, viruses, trojans, automated attack scripts, etc. The only missing piece is a local exploit -- and even then only if they need it. Even if the bar at the top is pretty high, only a few people need to get there.
I agree that the theoretical "attack surface" (and how is that measured by the way?) is larger without a SAK, but I'm questioning whether it's practically making a difference. I can just as easily bang up a screensaver in VB that asks for the user password to unlock -- how many users on an unfamiliar computer are going to know that they need to hit the SAK, THEN enter their password?
Holy shit. I'm having trouble believe you could even _suggest_ these two tasks are comparable in terms of difficulty and likelihood, let alone try and argue it.
I'm not saying the two tasks are both trivial, I am saying that the harder task has already been done and Windows script kiddies have everything they need. I could put together a "own this Windows box" CD in at most a week where last decade I would have had to become a master Win16/32 programmer.
As for likelihood, anecdotes are not data. Twenty years ago hacking public labs was commonplace because people had no other way to get online; now with everyone online the incentive for casual hacking has dropped sharply, also there is the fact that the legal punishments are far harsher today than they were back then. But at the same time, the tools for serious hacking are much more widely available. A targeted attack can almost always succeed even by a relatively inexperienced hacker.
Have you never had even passing experience with an environment like a school or call centre where individual machines are regularly used by dozens of different people ?
Yes I have. When I first got on the Internet 15 years ago people routinely had their terminals hosed by the infamous flash.c program. Viruses still propagated via floppies, and the Unix admins knew for sure that users had cracked some root passwords (shadow passwords were just coming in over there). The labs in those days ran DOS and Windows 3.1 and used NetWare for file serving. Nowadays, our local department lab allows logged in users to install anything and so we've always got a few systems being reimaged because of the gadzillion toolbars people like to install along with P2P clients, IM programs, etc. (FWIW our login procedure (NetWare) doesn't even use the SAK. It would be really easy to fake that screen right? Yet it hasn't happened...)
OTOH, the main access labs are locked down so tight it would be pretty hard to do anything on them. Though they do use the standard Windows SAK login they don't really need it: inactive users are automatically logged out, you cannot run executables from any media you can write to or from the network, there is no screensaver after you login, and the login screensaver is changed almost daily (people buy advertising on it). You enter your password once, do your stuff, and logout. The only way to fake a login screen would be through Office VBA, and then it would have to emulate the screensaver too.
This requires elevated privileges to accomplish. They are not a reasonable assumption.
You really need elevated privileges to put an entry in the user's startup folder? Give it the same appearance as MSOffice startup and the boss wouldn't even notice.
----
I won't beat this horse anymore, other than to point out one thing: ultimately, the end user already has zero guarantees that a
Neither of these are true. Firstly, it's not at all uncommon for input devices to be available, but the actual machine secured (eg: in a locked kiosk or another room).
Which makes no difference at all so long as the boot sequence goes directly to a password prompt.
Secondly, the ability to pop up a dialog box that looks like a login prompt on a user's screen does not in any way imply the ability to replace low-level system DLLs.
That's true, but flip it around: a user who can replace system DLLs already has the ability to subvert the SAK, so it buys nothing in that case. It only raises the bar for malicious users who are able to find/code a login lookalike but cannot find/code a local exploit. Again, that seems like a tiny use case to me.
Now if there were serious studies done that show that the population of users who can find Windows login lookalikes but not find local exploits is very large, then I might change my mind.
Imagine $MALICIOUS_EMPLOYEE wants to "snarf" his boss's login details so he can do $BAD_THINGS. All he needs is thirty seconds alone with his boss's PC to copy a login-spoofer off a network share and run it. This is the kind of thing a SAK is there to protect against.
See above. If I've got enough time to install a login lookalike, then I've got enough time to install a local exploit. Once that's done, game over. (Furthermore: In your use case MALICIOUS_EMPLOYEE likely has an even easier way to accomplish most of their BAD_THINGS: install a backdoor to load everytime the manager logs in and they can have network access to his/her security context and files ala NetBus / Back Orifice.)
As I said, unless the pool of users who can find login lookalikes but not find local exploits AND can't get their nefarious deeds done with something like Back Orifice is very large, SAK does little to improve overall security.
But does SAK really improve security? I would argue that in practice it is useless. As you pointed out yourself, physical access to the box permits full access to the CPU (though the data on the hard drive might remain encrypted) and if anyone can subvert the machine over the network then they could replace the login program itself with their own version that popped up when the SAK was hit.
Seems to me that SAK only buys you security if you assume that your OS is not already compromised AND a malicious user with physical access to the box who does not already have Administrator access is running a full-screen application that looks like a login prompt in order to snatch passwords AND they did not already install a hardware keylogger. Times have changed since ~1990, and this use case is very limited to me. The malicious user can just as easily find a local privilege exploit and snarf the entire password database and crack it at their leisure or just run an application that looks and behaves like Explorer.exe but records keystrokes.
Christ, with the standard linux install, I can log in as root without knowing the password if I have console access, just reboot and trigger single user mode during startup. How is that secure?
It's exactly as secure as any PC with a BIOS that allows booting from removable media. I can circumvent Windows security by booting a custom Linux, resetting the Administrator password, and then booting into Windows.
I COULD secure a Linux system by:
1) Enabling a BIOS password.
2) Allowing only booting off the hard drive.
3) Using LILO and forcing it to boot the kernel with no prompting for kernel parameters, hence no single-user mode before password.
This still leaves the ability to open the case and reset the BIOS or replace the hard drive.
No, it's "necessary" in Windows for the same reason it's "necessary" on all platforms. To ensure no other application is masquerading as a login screen.
If a SAK is so necessary, why don't other operating systems need one? (Note Linux has one, but few people even know what it is much less use it.)
The question is, if this architecture hangs around for the next couple of decade what will you be happy to have taken account for ?
I don't think x86 in its current form will last that long anyway. With Linux and OSX we are seeing that the underlying architecture is essentially irrelevant to applications and even kernels -- just update the compiler to output to the target instruction set and recompile it all over a few months. That my IDE chipset needs a window in the lower XXMB RAM for DMA is completely hidden to me.
I think in the next ten years we'll see the ia32 instruction set essentially vanish and 16-bit BIOSes disappear also (witness LinuxBIOS), especially as all machines move to multi-core.
That's amazing. Could you please outline for us your grocery list? Please also include all meals and drinks you eat out too, since that counts towards the OP's reference to the 2000 calorie minimum.
They will be interested precisely up until the point where they find that they can't play the games that they just bought from their local CompUSA (or PC World, or whatever).
I don't know about that. Most times I go into Best Buy the games are already segregated by platform: Xbox, PS2, Nintendo-whatever, PC, Mac. I think that so long as Linux is positioned as a separate platform people will understand that it is neither Mac nor Windows.
Back when I got my first computer, the stores even had separate shelves for Nintendo, Commodore, Atari games, Atari computers, Apple II, Mac, DOS, and Windows.
a) I feel that history has shown me at least that having only a single implementation of *anything* (especially something as important as GCC) is a bad thing in general terms.
I agree that standards are good and multiple implementations that meet a particular standard make that standard much stronger. However, I disagree that every piece of code MUST have competing F/OSS implementations. Example: pppd. We essentially all use the same version of pppd and it works well and has been mostly bug-free for over 10 years. Other examples more in line with this discussion are perl, Python, and Ruby. The reference implementations are the only implementations used but those languages have not really suffered as a result, especially since the reference implementations support so many platforms. I think where it really matters is F/OSS vs. proprietary software. Example: we were (are) all at the mercy of Sun's Java implementation until a F/OSS Java stack became viable. Now that Kaffe + Classpath can run 95% of Java software, developers can breathe easier about using that platform.
I suppose I would say the gaping chasm is between between proprietary software and F/OSS and this gap creates a lot of immediate problems for both users and developers. The much smaller cracks between various F/OSS licenses matters only to developers, and even then only to developers who wish to use community code in proprietary products. The latter gap would matter to me only if the GPL community code was the ONLY way to achieve a certain end; however, commercial products exist that force the community code to adhere to a standard so this problem does not seem critical to me.
b) Going on from a), I especially feel that a *license* monoculture with the license controlled by a single institution is an extremely bad thing, especially when said license is as strongly mutually exclusive as the GPL is.
I think everyone already agrees with this. Some code needs to be BSD/public domain/LGPL, and some code needs to be GPL. Witness the projects that had to switch to Postgres due to the GPL'd MySQL library.
However, though GPL is controlled by the FSF, developers are still the ultimate deciders in how their code is used, and as we have seen with Mozilla, Apache, and others developers have created a number of different licenses to reflect their needs. With so much of the regular stack under so many different licenses, GPL is (and always will be) one voice of many.
c) I do not trust Richard Stallman, and I never have. His own rhetoric about "freedom," notwithstanding, there are those of us who believe that the GPL was written expressly with the intent to create a monoculture in mind. I also feel that the behaviour of the FSF over the last 18 months or so has gradually been bearing this assertion out to an increasing degree. If we had access to a compiler under a license outside of the FSF's control, (my own suggestion would be the BSD license, but there are a lot of different options) those of us who no longer wish to be in any way associated with the FSF could still continue to use FOSS on our own terms, rather than theirs. It would also mean a radical reduction in factional conflict I suspect, since people like Bruce Perens and the Debian Project who agree with the FSF could continue to develop their own software and persue their own interests without continually trying to force their perspectives on those of us who do not agree. There are those of us who fervently wish that, while being able to continue to use open source in various forms, that we could otherwise forget about the FSF's existence entirely.
I expect RMS does indeed ultimately desire a GPL monoculture, but he is pursuing it by competing more-or-less fairly in the marketplace, not by stamping out the rest. I think it is wrong to say that RMS and Debian et al are "continually trying to force their perspectives" on everyone else. They have their code, they have their terms, and most people attacking them want their code u
I'll respond only because I've got 10 minutes to waste...
European countries use Windows for the same reason Americans do: MS rode the wave of personal computing and then began setting up illegal business deals to catapult itself into a monopoly position. They use Windows for the same reason you use Canadian, Venezualan, and OPEC oil: you have to. OTOH, they are taking the lead in moving away from Windows unlike many of their American counterparts.
Second, the Internet was NOT paid for by the USA. The current protocols were developed with DoD research dollars, but they were informed by experimental networks in Britian and elsewhere. The actual network hardware was purchased by them for their own networks, and for the most part that was all manufactured in Asia.
And BTW I am an American enrolled at a prominent Texas university in a top-tier engineering graduate program that has 90% international students.
Slashdot Mirror
...here come the "knee jerk" reactions, which - with Democrats in control of Congress - will almost certainly include new gun-control legislation.
Thanks for providing the required "OMG Liberals want to take our gunz!!" comment now that a tragedy involving firearms has occurred.
And for doing it within 6 minutes of the announcement, you get the special Gun-Luvin' Wingnut lapel pin!
Fucking asshole.
Well, if someone 'sane' in the bldg had been packing a weapon, they might have ended this asshole's rampage a bit earlier....
Or found their weapon stolen and had been used to kill even more people. Or been outgunned in a hall shootout in the same manner as the armed guard at Columbine.
This is breaking news, can we please all put down our politics until the story becomes more coherent?
Could you elaborate on this? When I used to write networking code I never "queried" to figure out what kind of protocol was installed.
IPv6 certainly did cause some disruption, but that was all caused by needing to support both AF_INET and AF_INET6 addresses. Once you switched from inet_addr() to inet_pton() and made sure to check sockaddr_in.sa_family_t, the rest of the code was pretty much the same.
He may have had a 49g+ which had crappy keyboards, but there has been NO reported breakage of the 50G keyboard. I've had one over a year before they were launched (beta testing) and mine is still going strong. It is used over 4 hours a day.
I'm glad yours is OK. My friends, however, is not. Believe whatever you want.
Between a good friend and I we have about 6 HP48 calculators, including (drum roll) one of the very last 48GX's ever made STILL UNOPENED in package. I've got two GXs and one G, he's got 2 GX's and an SX. He's also got a 50. The 50 lasted about six weeks into his electrical engineering coursework before the keys began breaking -- and it had already been replaced once under warranty. My main 48GX has survived the worst of a chemical engineering undergrad and still going strong.
The moral: the 50 is really nice, but is too flimsy to handle the real-world workload.
Looks like I've struck a nerve, here. Interesting...if what I'm saying is, "bullshit," then why bother getting so upset about it?
Oh, so after you insult every developer who doesn't use the BSD license (which as I noted is a pretty pointless license), now you want to backtrack and take the high road to impartiality. As you say, "interesting."
I suppose I was mistaken afterall, after seeing how nice and friendly you are now. You didn't REALLY mean to say outright that I and the several good developers I have worked with in the past only care about writing Microsoft knockoffs in our spare time, or that we are idiots who don't really understand the concept of community software. You must have been saying something else.
What a crock of shit! Only BSD developers love to code? Linux is driven by a hatred of Microsoft? Fuck you too.
You look in my posting history, you'll see I use GPL for a lot of my work. That's not because I fear Microsoft, it's because I want to get paid if a company wants to take my code. But I code anyway because I like to, I've got specific needs that aren't met by what I find out there so I start my own projects to get there.
But then I get to code that I don't care about getting paid for, or I want to use both inside and outside of work. That stuff is a gift: I license it public domain. I see no point in licensing code BSD when public domain is already well understood and out there. If you want credit, just make sure you have a web site and stick your project on your resume.
There are a lot of things that the FSF have done that I continue to feel outraged about, but polluting the original motivation behind open source has to be one of the very worst.
That's pretty rich, what are you smoking so we can get some?
The motivation has ALWAYS been about writing code. For some developers, they want to get paid too so they use GPL; others don't care or don't need to get paid, so they use BSD; still others use one of the many other existing OSS licenses for their own reasons.
You want to be pissed at FSF, fine, go write a compiler suite while you're at it. You want to be pissed at the thousands of developers who (shock!) love to write code but don't already agree with you, then too fucking bad for you. You want to argue about some ideological license purity bullshit? Then why the fuck are you using the BSD license instead of just leaving it in public domain?
Don't like my profanity? Tough shit. You say profane ideas, you get a profane response.
If your Mac-based network computer craters, can you beat that 20 minute turnaround time?
/var/cache/apt . ~2 minutes.
/etc/hosts, modify /etc/fstab to mount the NFS shares, modify /etc/group, /etc/passwd, and /etc/shadow to use NIS. ~2 minutes.
I can't tell you how a Mac would do it, but for me when one of my Debian Linux boxes crashes, restoring it is a 1-hour process:
1) Fix the hardware issue, which usually means replacing the hard drive or the entire box.
2) Boot on the Debian netinst CD. Partition the drive using the partition tool, let it install, reboot, and get on the network. ~10 minutes.
3) Copy the debs over: rsync -acv master:/var/cache/apt/archives
4) Copy the base build package selections over: scp master:selections ~ . ~10 seconds.
5) Select the base build: dpkg --set-selections < selections . ~10 seconds.
6) Run dselect to install everything. Answer the questions as appropriate. ~2 minutes.
7) Let dselect do the actual installation. ~30 minutes.
8) Copy over
9) Take the box to whatever room it belongs in.
10) DONE.
At the end of this procedure the box has been configured from bare metal to the standard build which includes quite a bit of application and development software, NIS and NFS are there so users have full access to their existing setups, and everything is up-to-date with security patches.
Granted, I don't do Windows support, but the closest I have ever come to this in Windows is using either Partition Magic or Ghost to get a drive re-imaged, and even then I have to bypass the Microsoft installer, Windows update, and dozens of application software installers that can each take 10-30 minutes to get through. Or in the case of Visual Studio.NET, almost 3 hours.
Is this code from IGS or an actual shipped product e.g. DB2, WAS, etc.?
I'd like to know the story behind those two products. How could the same company produce two products with such disparate quality?
This is what I heard while working for one of the WebSphere applications group. Eclipse was developed by a company IBM had acquired whose name escapes me -- started with an O I think. Anyway, even though they were IBM, they weren't "IBM": they used completely different tools for their work, had access to most of IBM's codebase but provided almost none of their own back to the rest of the company -- much like the Lotus group. The people in WebSphere were exasperated at them because they delayed delivery so long to develop SWT when (it was assumed) they could have just modified Swing to achieve the same effect. Finally, Eclipse was first and foremost meant to be a direct competitor to Visual Studio and cost a lot of money. After quite a few years (I got the impression 5-10 years from the dev talking to me), IBM had sunk about $30 million into Eclipse and still had no shipping products.
It was released as OSS when it became obvious that IBM could not possibly take on Visual Studio in the Windows environment: Eclipse was too slow, too big, and too feature-poor compared even to VS '97. Of course, IBM didn't know that VS.Net was going to be much bigger, much slower, and take all its new feature cues from Visual Basic. Regardless, IBM correctly realized that after the initial bug-fixing and stability issues were addressed, they could use the OSS base to build their ultimate dev platform: WSAD. (However, as of 2003, the devs I knew within IBM who had both Eclipse/WSAD and NetBeans preferred NetBeans.)
Visual Age was originally from the Smalltalk product line. (I knew a few developers who had once been on that team, unfortunately their skills didn't translate very well into Java for their later work.) VAJava was meant to go up against Visual J++, Symantec cafe-something-or-other, and the Borland Java. Back in 1999 it was a reasonable competitor in that field (remember that was back when Java IDEs were very new and crash-prone). About that time were the first serious Java desktop applications, and people began to see that Java was too slow on that generation of hardware, hence VAJava languished until Eclipse delivered the death blow.
Since you asked about how IBM can be so schizophrenic, here is my take on the bigger picture. The IBMers who grew up on the mainframe and AIX can write some seriously good code with lots of excellent diagnostics. (Go read the DB2 message reference sometime.) However, IBM's ultimate problem is its desire within management to create "solutions" for businesspeople. So they tend to take products that work well in their respective domains and "IBM-ize" them into things unlike anything else in the market. Hence AIX has a C++ compiler that creates highly optimized code but is even worse to deal with than VC++. AIX is also so unique that almost no one outside IBM is qualified to work on it, yet it is a fantastic operating system and combined with DB2 makes the best datastore I have ever seen. When they buy products from small companies (like the original WebSphere server) they alter the company culture so much that all the good talent leaves and then they spend two product lifecycles just developing inhouse skill to essentially re-create the product from scratch. OTOH, when they buy companies too large to do that with (like Lotus) they end up with these rogue units producing code that barely works at all within the rest of the IBM landscape.
As far as their product lines go, you can tell easily which group makes what. DB2 comes out of the Server Group, who mostly do big iron hardware, hence DB2 rocks. WebSphere comes out of the Software Group, which is mostly Windows weenies who STILL don't understand that case-sensitive filesystems exist and not everything written in Java needs to run as root. Code from IGS can't be installed without a consultant because they haven't learned how to use 'make' from Server Group. Code you get from IBM Research is lucky to compile at all.
The biggest problem isn't about just the anti-tivoization problems or what ever. It's the fact that the new rules are not well written, they are based on simple problems that the FSF has had with GPL v2.
Welcome to the real world. Go look up your local government's property code for an astonishingly large collection of laws designed to prevent people from being assholes with rented property. It's almost as if there is always some significant part of the population whose sole aim in life is to fuck things up for everyone else.
My freedom ends at the tip of your nose.
Your freedom ends quite a bit further from me than that...
If Linus blesses a fork, I'd say it's a pretty safe bet that his is going to trounce the FSF one.
If this was 1996 I'd agree with you. Now, not so much. The other kernel developers have lots of code in there and reasons of their own to maintain compatibility with glibc at any version. Remember how many people needed to use -mm and -ac versions of the kernel at different times? Those are forks maintained by other high-ranking kernel developers.
GNU libc is LGPL obvs so that doesn't matter.
If you are Tivo it matters a great deal. LGPL stipulates that the library is still replaceable by the end user and hence the DRM lockdown can be trivially circumvented.
Perhaps you were thinking about a commercial app that can link to glibc but keep its code closed.
Or you could just rationally and objectively think about the relative difficulties of coding up a windows app that masquerades as a login screen vs replacing system level DLLs as an unprivileged user for more than a minute or two.
"Rationally and objectively" usually is a euphemism for "you need to think like me"...
Crackers don't need to know how to code. People who know how to code have already written all the utilities they need. Rootkits: done. Network backdoors: done. Network scanning, viruses, trojans, automated attack scripts, etc. The only missing piece is a local exploit -- and even then only if they need it. Even if the bar at the top is pretty high, only a few people need to get there.
I agree that the theoretical "attack surface" (and how is that measured by the way?) is larger without a SAK, but I'm questioning whether it's practically making a difference. I can just as easily bang up a screensaver in VB that asks for the user password to unlock -- how many users on an unfamiliar computer are going to know that they need to hit the SAK, THEN enter their password?
Holy shit. I'm having trouble believe you could even _suggest_ these two tasks are comparable in terms of difficulty and likelihood, let alone try and argue it.
I'm not saying the two tasks are both trivial, I am saying that the harder task has already been done and Windows script kiddies have everything they need. I could put together a "own this Windows box" CD in at most a week where last decade I would have had to become a master Win16/32 programmer.
As for likelihood, anecdotes are not data. Twenty years ago hacking public labs was commonplace because people had no other way to get online; now with everyone online the incentive for casual hacking has dropped sharply, also there is the fact that the legal punishments are far harsher today than they were back then. But at the same time, the tools for serious hacking are much more widely available. A targeted attack can almost always succeed even by a relatively inexperienced hacker.
Have you never had even passing experience with an environment like a school or call centre where individual machines are regularly used by dozens of different people ?
Yes I have. When I first got on the Internet 15 years ago people routinely had their terminals hosed by the infamous flash.c program. Viruses still propagated via floppies, and the Unix admins knew for sure that users had cracked some root passwords (shadow passwords were just coming in over there). The labs in those days ran DOS and Windows 3.1 and used NetWare for file serving. Nowadays, our local department lab allows logged in users to install anything and so we've always got a few systems being reimaged because of the gadzillion toolbars people like to install along with P2P clients, IM programs, etc. (FWIW our login procedure (NetWare) doesn't even use the SAK. It would be really easy to fake that screen right? Yet it hasn't happened...)
OTOH, the main access labs are locked down so tight it would be pretty hard to do anything on them. Though they do use the standard Windows SAK login they don't really need it: inactive users are automatically logged out, you cannot run executables from any media you can write to or from the network, there is no screensaver after you login, and the login screensaver is changed almost daily (people buy advertising on it). You enter your password once, do your stuff, and logout. The only way to fake a login screen would be through Office VBA, and then it would have to emulate the screensaver too.
This requires elevated privileges to accomplish. They are not a reasonable assumption.
You really need elevated privileges to put an entry in the user's startup folder? Give it the same appearance as MSOffice startup and the boss wouldn't even notice.
----
I won't beat this horse anymore, other than to point out one thing: ultimately, the end user already has zero guarantees that a
"Boots"? Does the user always have authority to shut down the machine and make sure that it has in fact just booted?
What are you getting at? Are you trying to imply that somehow SAK on Windows provides a security advantage?
Neither of these are true. Firstly, it's not at all uncommon for input devices to be available, but the actual machine secured (eg: in a locked kiosk or another room).
Which makes no difference at all so long as the boot sequence goes directly to a password prompt.
Secondly, the ability to pop up a dialog box that looks like a login prompt on a user's screen does not in any way imply the ability to replace low-level system DLLs.
That's true, but flip it around: a user who can replace system DLLs already has the ability to subvert the SAK, so it buys nothing in that case. It only raises the bar for malicious users who are able to find/code a login lookalike but cannot find/code a local exploit. Again, that seems like a tiny use case to me.
Now if there were serious studies done that show that the population of users who can find Windows login lookalikes but not find local exploits is very large, then I might change my mind.
Imagine $MALICIOUS_EMPLOYEE wants to "snarf" his boss's login details so he can do $BAD_THINGS. All he needs is thirty seconds alone with his boss's PC to copy a login-spoofer off a network share and run it. This is the kind of thing a SAK is there to protect against.
See above. If I've got enough time to install a login lookalike, then I've got enough time to install a local exploit. Once that's done, game over. (Furthermore: In your use case MALICIOUS_EMPLOYEE likely has an even easier way to accomplish most of their BAD_THINGS: install a backdoor to load everytime the manager logs in and they can have network access to his/her security context and files ala NetBus / Back Orifice.)
As I said, unless the pool of users who can find login lookalikes but not find local exploits AND can't get their nefarious deeds done with something like Back Orifice is very large, SAK does little to improve overall security.
And how does this imply that SAK is a valuable security feature?
So long as the OS is already secure and boots directly to a password prompt the SAK is just one more step in the login process.
Its a feature because it enables better security.
But does SAK really improve security? I would argue that in practice it is useless. As you pointed out yourself, physical access to the box permits full access to the CPU (though the data on the hard drive might remain encrypted) and if anyone can subvert the machine over the network then they could replace the login program itself with their own version that popped up when the SAK was hit.
Seems to me that SAK only buys you security if you assume that your OS is not already compromised AND a malicious user with physical access to the box who does not already have Administrator access is running a full-screen application that looks like a login prompt in order to snatch passwords AND they did not already install a hardware keylogger. Times have changed since ~1990, and this use case is very limited to me. The malicious user can just as easily find a local privilege exploit and snarf the entire password database and crack it at their leisure or just run an application that looks and behaves like Explorer.exe but records keystrokes.
Christ, with the standard linux install, I can log in as root without knowing the password if I have console access, just reboot and trigger single user mode during startup. How is that secure?
It's exactly as secure as any PC with a BIOS that allows booting from removable media. I can circumvent Windows security by booting a custom Linux, resetting the Administrator password, and then booting into Windows.
I COULD secure a Linux system by:
1) Enabling a BIOS password.
2) Allowing only booting off the hard drive.
3) Using LILO and forcing it to boot the kernel with no prompting for kernel parameters, hence no single-user mode before password.
This still leaves the ability to open the case and reset the BIOS or replace the hard drive.
No, it's "necessary" in Windows for the same reason it's "necessary" on all platforms. To ensure no other application is masquerading as a login screen.
If a SAK is so necessary, why don't other operating systems need one? (Note Linux has one, but few people even know what it is much less use it.)
The question is, if this architecture hangs around for the next couple of decade what will you be happy to have taken account for ?
I don't think x86 in its current form will last that long anyway. With Linux and OSX we are seeing that the underlying architecture is essentially irrelevant to applications and even kernels -- just update the compiler to output to the target instruction set and recompile it all over a few months. That my IDE chipset needs a window in the lower XXMB RAM for DMA is completely hidden to me.
I think in the next ten years we'll see the ia32 instruction set essentially vanish and 16-bit BIOSes disappear also (witness LinuxBIOS), especially as all machines move to multi-core.
I spend no more than $15/week on my groceries.
That's amazing. Could you please outline for us your grocery list? Please also include all meals and drinks you eat out too, since that counts towards the OP's reference to the 2000 calorie minimum.
They will be interested precisely up until the point where they find that they can't play the games that they just bought from their local CompUSA (or PC World, or whatever).
I don't know about that. Most times I go into Best Buy the games are already segregated by platform: Xbox, PS2, Nintendo-whatever, PC, Mac. I think that so long as Linux is positioned as a separate platform people will understand that it is neither Mac nor Windows.
Back when I got my first computer, the stores even had separate shelves for Nintendo, Commodore, Atari games, Atari computers, Apple II, Mac, DOS, and Windows.
a) I feel that history has shown me at least that having only a single implementation of *anything* (especially something as important as GCC) is a bad thing in general terms.
I agree that standards are good and multiple implementations that meet a particular standard make that standard much stronger. However, I disagree that every piece of code MUST have competing F/OSS implementations. Example: pppd. We essentially all use the same version of pppd and it works well and has been mostly bug-free for over 10 years. Other examples more in line with this discussion are perl, Python, and Ruby. The reference implementations are the only implementations used but those languages have not really suffered as a result, especially since the reference implementations support so many platforms. I think where it really matters is F/OSS vs. proprietary software. Example: we were (are) all at the mercy of Sun's Java implementation until a F/OSS Java stack became viable. Now that Kaffe + Classpath can run 95% of Java software, developers can breathe easier about using that platform.
I suppose I would say the gaping chasm is between between proprietary software and F/OSS and this gap creates a lot of immediate problems for both users and developers. The much smaller cracks between various F/OSS licenses matters only to developers, and even then only to developers who wish to use community code in proprietary products. The latter gap would matter to me only if the GPL community code was the ONLY way to achieve a certain end; however, commercial products exist that force the community code to adhere to a standard so this problem does not seem critical to me.
b) Going on from a), I especially feel that a *license* monoculture with the license controlled by a single institution is an extremely bad thing, especially when said license is as strongly mutually exclusive as the GPL is.
I think everyone already agrees with this. Some code needs to be BSD/public domain/LGPL, and some code needs to be GPL. Witness the projects that had to switch to Postgres due to the GPL'd MySQL library.
However, though GPL is controlled by the FSF, developers are still the ultimate deciders in how their code is used, and as we have seen with Mozilla, Apache, and others developers have created a number of different licenses to reflect their needs. With so much of the regular stack under so many different licenses, GPL is (and always will be) one voice of many.
c) I do not trust Richard Stallman, and I never have. His own rhetoric about "freedom," notwithstanding, there are those of us who believe that the GPL was written expressly with the intent to create a monoculture in mind. I also feel that the behaviour of the FSF over the last 18 months or so has gradually been bearing this assertion out to an increasing degree. If we had access to a compiler under a license outside of the FSF's control, (my own suggestion would be the BSD license, but there are a lot of different options) those of us who no longer wish to be in any way associated with the FSF could still continue to use FOSS on our own terms, rather than theirs. It would also mean a radical reduction in factional conflict I suspect, since people like Bruce Perens and the Debian Project who agree with the FSF could continue to develop their own software and persue their own interests without continually trying to force their perspectives on those of us who do not agree. There are those of us who fervently wish that, while being able to continue to use open source in various forms, that we could otherwise forget about the FSF's existence entirely.
I expect RMS does indeed ultimately desire a GPL monoculture, but he is pursuing it by competing more-or-less fairly in the marketplace, not by stamping out the rest. I think it is wrong to say that RMS and Debian et al are "continually trying to force their perspectives" on everyone else. They have their code, they have their terms, and most people attacking them want their code u
I'll respond only because I've got 10 minutes to waste...
European countries use Windows for the same reason Americans do: MS rode the wave of personal computing and then began setting up illegal business deals to catapult itself into a monopoly position. They use Windows for the same reason you use Canadian, Venezualan, and OPEC oil: you have to. OTOH, they are taking the lead in moving away from Windows unlike many of their American counterparts.
Second, the Internet was NOT paid for by the USA. The current protocols were developed with DoD research dollars, but they were informed by experimental networks in Britian and elsewhere. The actual network hardware was purchased by them for their own networks, and for the most part that was all manufactured in Asia.
And BTW I am an American enrolled at a prominent Texas university in a top-tier engineering graduate program that has 90% international students.