Oh, how I'd like that for a change. Say what you will, fixing a Linux system is far, far easier than fixing any problem on Windows. Since, you know, Linux is actually fixable. With Windows, most errors aren't even debuggable, and the few ones that are, are instead unfixable (like spyware that has grabbed ten different methods of being autostarted on boot, etc.), so it almost invariable ends up with a "Well, I'll just have to reinstall that for you", and they you're stuck for many hours backing up, reinstalling Windows, reinstalling twenty drivers and application programs and restoring data. Indeed, I'll prefer fixing Linux desktops any day.
It's easy for you to say that, but in reality, things aren't that easy. I spent months trying to find a good WiFi card for Linux before I actually did, and I did check online documentation first to see that it should work. I went through, I think, 4 cards that were "supposed" to work in Linux, but didn't, because, as the GP said, they had different chipsets despite being the same model number. Even looking at the revision numbers hardly worked, as demonstrated by my favorite failure -- I don't remember the make and model, but the one supposed to work with Linux was v2 of the model. They failed to mention, however, that v2 meant the second revision of the first version of the card, not the second version of the card, which came with a completely unsupported Marvell chipset.
Eventually, I figured out that the best bet seems to be to get a "NoName" Taiwanese card, since Asian companies seem to be much more comfortable with handing out specifications for the products than US companies. I found a Ralink-based card by "Gigabyte Corporation". Even so, the Linux driver was alpha quality, to say the least, so I am now running FreeBSD on the laptop it was intended for (not an entirely bad side effect, admittedly).
Anyway, the point was that it really isn't easy to find a card that works with Linux, regardless of whether it's supposed to work, since the vendors really seem to be trying their very best to conceal what chipset is actually inside the RF shield. Really, how hard would it be to just print the PCI ID somewhere on the box? Now that I think about it, I'm almost beginning to wonder if it isn't a Microsoftish conspiracy, all of it.:)
Aside from the jokes, am I the only one who am more than a bit disturbed by Intel's CSI (apparently "Common System Interface")? Did they actually find anything really bad about HyperTransport that TFA fails to mention, or is it just a horrid example of the NIH syndrome?
Still, you are right, all-in-one cpus are the future, we're just not quite there yet.
Actually, no thank you. I've had enough problems ever since they started to integrate more and more peripherals on the motherboard. I'd be troubled if I'd have to choose between either a VMX-less, DDR3-capable chip with the GPU I wanted, a VMX- and DDR3-capable chip with a bad GPU, a VMX-capable but DDR2 chip with a good GPU, or a chip that has all three but an IO-APIC that isn't supported by Linux, or a chip that I could actually use but costs $500.
Instead of gaining those last 10% of performance, I'd prefer a modular architecture, thank you. Whatever is so terribly wrong with PCI-Express anyway?
Not only that, but I suspect that it is in fact far from what the title appears to want. The fact that it is Microsoft which has lost the lawsuit makes me think that it's just going to get worse for everyone instead. I mean, think about it for just a millisecond: Microsoft loses the right to distribute MP3 decoders with Windows -- What do you think will happen:
They turn around 180 degrees and include a Vorbis decoder with every version of Windows.
They advertise WMA even more than before.
Emphasizing, again, that this is Microsoft, which do you think seems more likely?
The really stupid part about UAC, as I see it, is this:
The anti-password-keylogging protection which you mention is at least initiated by the user, by pressing Ctrl-Alt-Delete, which the Windows kernel treats specially and only dispatches to the security subsystem -- therefore, it is impossible to write a trojan which would simulate the Windows C-A-D logon procedure, since the trojan couldn't know if the user presses C-A-D.
On the other hand, a UAC prompt, at least as I've understood it, is initiated by programmatic action. The way I've understood it is basically that if a process tries to do something which would normally return some kind of EACCES/EPERM error (whatever it's called in Windows), the system catches it, displays a UAC prompt and, if the prompt isn't denied, raises the privilege level of the calling process as required not to return EACCES/EPERM. However, since the action is initiated programmatically, I don't understand why a process can't simply fake the "secure desktop" by fabricating a look-alike. It would be the perfect way to steal the password from a non-privileged user. Also, as another commenter mentioned, UAC seems to allow for a rather nasty DoS attack by means of simply doing a UAC-prompting action in an infinite loop, since it is system-modal (thanks to the secure desktop). Of course, there are also the other numerous problems with UAC, like the user just getting used to clicking "allow" whatever is prompted for.
Unix had it right from the beginning, by having "su" or "sudo" being a user-initiated action. I'm quite a bit against the newfangled behavior of modern distros to automatically ask for the su/sudo password whenever an administrative program is launched from the program menu -- it moves it a bit closer to how UAC does it. Instead, I would think it better to have a tray icon or similar, which the user can click on, be prompted for the password, and thenceforth having programmatic sudo automatically acknowledged until the tray icon is instructed to deny it again or until a timeout passes -- much like sudo currently works.
Irony? I would tend to disagree -- rather, I think it is to be expected. Snort is a perfect example of the kind of "solution" that, instead of fixing the real problems, just adds another layer on top of everything to cover them, increasing the overall complexity of the system, and the more complex a system gets, the more likely it is to show unexpected behavior. That kind of reasoning also perfectly well explains why Windows will never be as secure as any Unix flavor.
I'm not sure exactly what you're referring to, but I would argue it is the other way around. If you use OpenID to sign in to a spoofed site, you're safe, because they can't use that info to sign in to the real site themselves. If they're spoofing your OpenID server, then, to be honest, people would be fooled just as much or little as they would be without OpenID. On top of that, OpenID allows you to do neat things like SSL client certificate or Kerberos authentication or anything else that cannot be used by phishers any way. I would also think that some ISPs (like AOL) could use that to make client certificate authentication automatic for their users. That way, it may actually put an effective stop to phishing.
I hadn't heard of OpenPrivacy before, so I didn't know what it was. After having read around a bit on their site, though, I still can't say I do. It seems to be a much larger project than OpenID is. It seems indeed that they have some authentication stuff in their as well, but they seem to be doing lots and lots of other things as well.
OpenID, on the other hand, is simply authentication and nothing more. The idea is that you only need one OpenID account. Then, when you go to a website which requires logon for some or all features (and which also supports OpenID) like Slashdot or any phpBB site, instead of the normal process of creating a user account with a password, you simply enter your OpenID URL or XRL and you get to authenticate yourself with the OpenID server instead. Just one account, one password and, if the OpenID server supports it, single sign-on in the way that you only have to enter your password once, and then the OpenID server will remember your browser (per some cookie) and automatically authenticate it to any other site you visit subsequently.
It's really quite neat. See, anyone can run their own OpenID server, and since it is the OpenID server that takes care of the authentication, it means that you can get SSL client certificate or Kerberos authentication for any other site you visit. You can even invent your own entirely new authentication scheme and use it on any OpenID-supporting site, since the site itself is agnostic with regards to the authentication method.
Briefly, it works like this: 1) You visit a website and type in your OpenID URL. 2) The web server fetches the URL and gets the OpenID server info from it. 3) It redirects your browser to the OpenID server. 4) You authenticate with the OpenID server. 5) The OpenID server redirects your browser back to whence it came, with some cryptographic info constructed from the authentication. 6) The original web server contacts the OpenID server to verify the info passed to it by the browser. 7) You're logged in! The scheme has some additional, optionally supportable optimizations as well, to decrease the number of HTTP roundtrips.
The tracking doesn't primarily depend on the authentication server's ability to log whenever you authenticate, but rather that having single sign-on drastically increases your tendency to reuse the same identity on every website you log into. In other words, cross-site tracking be done much more reliably than before.
Of course, many here on Slashdot could probably set up their own OpenID server that has a unique identifier for each site, but how many do you think {are going to/are able to} do that -- especially among AOL users?
Actually, when using NetworkManager, the nm-applet, running as the user, will save the settings in the user's home directory. It connects to the main nm process (running as root) through the system d-bus, normally being authorized by pam_console. No prompts, and still perfectly secure.
Furthermore, I think it's kind of weird to say that it's "one processor". It may be one chip, but is a processor defined by its die? Since it's an 80-core chip, isn't it more accurate to say that it's 80 CPUs on one die, just as a dual-core chip is rather two CPUs on one die? It's not as if it isn't impressive, but I think it's kind of misleading to say that it's just one processor.
If I'm crafting an attack, I don't have to even tell the truth about my IP address, TCP allows the sender to specify a (fake) IP address. Obviously I won't get any replies, but I don't care if I'm simply out to cause damage
I can't say that I have much in the way of statistics to back this up with, but I'd imagine that the vast majority of ISPs out there would refuse to route such a packet.
Quiet easily: It sucks just as much now as it did twenty years ago and every year thence. It's definitely not compilers getting worse, and although I don't know, I kind of doubt it ever was the programmers' fault that Windows is as it is.
Every single day, they come out with a total exploit, your machine can be taken over totally.
Well first off, this just plain isn't true.
Oh, Sir, you are obviously mistaken. See, you have to consider the time frame. First of all, OS X has only at all existed since 2000, so before that, no exploits could possible have come out. Thus, we have to limit or timeframe to at least 2001-present. Then obviously, you have to limit the timeframe to 2007-01-28, at which time MoAB coincidentally discovered the horrible bug that leads to admin-group users being capable of executing code as root(!). See, every single day!
Good idea. I'll just tell all the developers to user port 8080.
Well now, my point was, of course, not that everyone should use port 8080 instead of port 80, but rather that simply using another port than the default often fixes the problem in question. My point about 8080 in particular was that it is >1024 and therefore bindable by !root.
Hello? McFly? See this bug? [Snip code taking 100% CPU]
Since when did hogging the CPU crash anything? I run Gentoo and often have 1 or 2 emerge instances running in the background (each using -j2 to make) on a comparatively slow UP machine (AMD XP 2200+, 1 GB RAM) while doing other things without even thinking about it. Especially, then, when such a process is stoppable within seconds, and many timesharing servers would probably even be SMP machines.
How about this one? [Snip code eating all memory]
"uname -Sv 200000"
You should see some of the multithreaded code people write. Ugh. Can you say, "Thread Bomb?"
Either that, or fork bomb. Add "uname -Sr 30" and maybe a fair share scheduler.
Then you're not doing anything involving. Fun things like changing the screen resolution and obtaining a DirectX context can crash or lockup your system. Or accessing external hardware at just the wrong time. (Yes, this happens on Unix as well. Though to somewhat lesser degrees due to focus on stablility rather than performance.) Never locked up an X-Session before? Then you're not doing anywhere near anything interesting.
Indeed, I have only extremely seldomly had my machine crash because of weird hardware access. Buggy device drivers? I have most definitely never had to reboot because of a locked up X-Session (Ctrl+Alt+Backspace and log in again).
[/specific rebuttals]
Anyway, my point was never that noone may ever, under any circumstances, need their own machine. I did mention kernel/driver work in my original post (although the ITS developers sure seemed to get things done even despite that), and although I was ignorant before your post (And happy! Damn you for destroying my pure innocent eyes!;), I am hardly surprised that development under Windows has special requirements (Windows seems that have that effect on a great many things). My point, however, was that there almost seems to be a general stigma (I've seen it in many other places as well) that developers cannot timeshare a system, and considering how the vast majority of developers are very unlikely to require their own boxes for any of the reasons stated above, I didn't understand whence that stigma has come.
I need to be able to run web servers and the like. Having a dozen developers trying to open port 80 on the same machine is a problem.
That's why I run my web server on port 8080 when programming. Sure, port allocation might become an issue if there is a huge number of developers on the same system, but certainly not unsurmountable.
Not to mention the excess computing resources used or outright crashes that a developer might accidently cause while debugging.
I'm pretty sure my emacs and gdb session takes less than a fifth of the memory used by Firefox or OOo, though. And since when did debugging cause system crashes? For sure, I've never experienced that or anything even remotely like it. Is that some kind of Windows issue?
I can't believe I see people using that command all around. Instead of spawning two extra processes with two extra execs, why not just run "sudo -i" or "sudo sh"?
The problem is that we developers are some of the few who actually need workstations, meaning that we often fail to push the best solution for the company as a whole.
This is a quote I've heard often, but never really understood. I, too, do a lot of programming, both for a living, for my university studies and in my spare time, and I only very seldomly (if ever) need root access for any of that work. I could understand it if one does kernel/driver work, but for normal application development, why would one need one's own workstation? I've always been fine with compiling and installing into my home directory for testing and for final usage of a program.
Care to explain for me? Is this, mayhap, some kind of Windows thing that I don't understand?
I most definitely disagree with you on that point. Except for things like bit-banging and polling, I think as much as possible should be done by the main processor. It usually only wastes a minimal amount of cycles anyway, and the advantage is that it is much easier to replace and fine-tune code to do exactly what you want it to do, rather than relying on pre-programmed or hardwired functionality in a peripheral. For example, if WiFi framing and RC4 encryption for WEP had been implemented in the driver instead of on the card, noone would need new cards to support WPA2 and AES -- just a driver update would have sufficed.
It isn't hard at all. Emacs has all these nifty functions where you can press M-C-(normal navigation keys) to move along balanced expressions, such as forward to the end of the current parenthesized expression in c-mode or back and forth s-exps in lisps. M-C-f for forward, M-C-b for backward M-C-u to go up one level, and, oh, M-C-DEL to delete one balanced expression backwards. Oops! I've done it several times.
You were modded funny, but that really was my first reaction. I was convinced it would be more than that. Sure, the corporate installs may well help keeping the number low, but virtually noone (at least noone I can think of right now) I know who runs Windows on their home PC runs a legal copy of Windows. Then there are all the stories about south east Asia and South America -- I haven't been there and looked for myself, but if one believes many of the stories on the web (certainly some of them spread by the BSA and/or MS themselves, admittedly), one would think that there isn't a single legal copy of Windows installed there.
Sure, I was probably just living in my own little world fabricated from stories on the web, but I was honestly surprised it was so low.
An interesting thing to know would be whether these reports are gathered from all over the world or just from North America. (Did TFA tell this? I hope noone expects me having read it.:) I would love seeing it if Microsoft decided to publish a detailed geographic report.:)
I may or may not agree with you, but I don't think that is the point of this whole article. Say that you have ~100 DRM:ed songs in your iTunes library, and then go to your nearest HiFi store and see, say, a nice Creative Zen MP3 player (well, it's not likely to be a Zune;) that you think would be better than your iPod. Would you then be able to buy that Zen player and not having to spend $100+ on rebuying all your current music to go onto it?
Slashdot Mirror
Oh, how I'd like that for a change. Say what you will, fixing a Linux system is far, far easier than fixing any problem on Windows. Since, you know, Linux is actually fixable. With Windows, most errors aren't even debuggable, and the few ones that are, are instead unfixable (like spyware that has grabbed ten different methods of being autostarted on boot, etc.), so it almost invariable ends up with a "Well, I'll just have to reinstall that for you", and they you're stuck for many hours backing up, reinstalling Windows, reinstalling twenty drivers and application programs and restoring data. Indeed, I'll prefer fixing Linux desktops any day.
Eventually, I figured out that the best bet seems to be to get a "NoName" Taiwanese card, since Asian companies seem to be much more comfortable with handing out specifications for the products than US companies. I found a Ralink-based card by "Gigabyte Corporation". Even so, the Linux driver was alpha quality, to say the least, so I am now running FreeBSD on the laptop it was intended for (not an entirely bad side effect, admittedly).
Anyway, the point was that it really isn't easy to find a card that works with Linux, regardless of whether it's supposed to work, since the vendors really seem to be trying their very best to conceal what chipset is actually inside the RF shield. Really, how hard would it be to just print the PCI ID somewhere on the box? Now that I think about it, I'm almost beginning to wonder if it isn't a Microsoftish conspiracy, all of it. :)
Aside from the jokes, am I the only one who am more than a bit disturbed by Intel's CSI (apparently "Common System Interface")? Did they actually find anything really bad about HyperTransport that TFA fails to mention, or is it just a horrid example of the NIH syndrome?
Actually, no thank you. I've had enough problems ever since they started to integrate more and more peripherals on the motherboard. I'd be troubled if I'd have to choose between either a VMX-less, DDR3-capable chip with the GPU I wanted, a VMX- and DDR3-capable chip with a bad GPU, a VMX-capable but DDR2 chip with a good GPU, or a chip that has all three but an IO-APIC that isn't supported by Linux, or a chip that I could actually use but costs $500.
Instead of gaining those last 10% of performance, I'd prefer a modular architecture, thank you. Whatever is so terribly wrong with PCI-Express anyway?
- They turn around 180 degrees and include a Vorbis decoder with every version of Windows.
- They advertise WMA even more than before.
Emphasizing, again, that this is Microsoft, which do you think seems more likely?The anti-password-keylogging protection which you mention is at least initiated by the user, by pressing Ctrl-Alt-Delete, which the Windows kernel treats specially and only dispatches to the security subsystem -- therefore, it is impossible to write a trojan which would simulate the Windows C-A-D logon procedure, since the trojan couldn't know if the user presses C-A-D.
On the other hand, a UAC prompt, at least as I've understood it, is initiated by programmatic action. The way I've understood it is basically that if a process tries to do something which would normally return some kind of EACCES/EPERM error (whatever it's called in Windows), the system catches it, displays a UAC prompt and, if the prompt isn't denied, raises the privilege level of the calling process as required not to return EACCES/EPERM. However, since the action is initiated programmatically, I don't understand why a process can't simply fake the "secure desktop" by fabricating a look-alike. It would be the perfect way to steal the password from a non-privileged user. Also, as another commenter mentioned, UAC seems to allow for a rather nasty DoS attack by means of simply doing a UAC-prompting action in an infinite loop, since it is system-modal (thanks to the secure desktop). Of course, there are also the other numerous problems with UAC, like the user just getting used to clicking "allow" whatever is prompted for.
Unix had it right from the beginning, by having "su" or "sudo" being a user-initiated action. I'm quite a bit against the newfangled behavior of modern distros to automatically ask for the su/sudo password whenever an administrative program is launched from the program menu -- it moves it a bit closer to how UAC does it. Instead, I would think it better to have a tray icon or similar, which the user can click on, be prompted for the password, and thenceforth having programmatic sudo automatically acknowledged until the tray icon is instructed to deny it again or until a timeout passes -- much like sudo currently works.
Irony? I would tend to disagree -- rather, I think it is to be expected. Snort is a perfect example of the kind of "solution" that, instead of fixing the real problems, just adds another layer on top of everything to cover them, increasing the overall complexity of the system, and the more complex a system gets, the more likely it is to show unexpected behavior. That kind of reasoning also perfectly well explains why Windows will never be as secure as any Unix flavor.
I'm not sure exactly what you're referring to, but I would argue it is the other way around. If you use OpenID to sign in to a spoofed site, you're safe, because they can't use that info to sign in to the real site themselves. If they're spoofing your OpenID server, then, to be honest, people would be fooled just as much or little as they would be without OpenID. On top of that, OpenID allows you to do neat things like SSL client certificate or Kerberos authentication or anything else that cannot be used by phishers any way. I would also think that some ISPs (like AOL) could use that to make client certificate authentication automatic for their users. That way, it may actually put an effective stop to phishing.
OpenID, on the other hand, is simply authentication and nothing more. The idea is that you only need one OpenID account. Then, when you go to a website which requires logon for some or all features (and which also supports OpenID) like Slashdot or any phpBB site, instead of the normal process of creating a user account with a password, you simply enter your OpenID URL or XRL and you get to authenticate yourself with the OpenID server instead. Just one account, one password and, if the OpenID server supports it, single sign-on in the way that you only have to enter your password once, and then the OpenID server will remember your browser (per some cookie) and automatically authenticate it to any other site you visit subsequently.
It's really quite neat. See, anyone can run their own OpenID server, and since it is the OpenID server that takes care of the authentication, it means that you can get SSL client certificate or Kerberos authentication for any other site you visit. You can even invent your own entirely new authentication scheme and use it on any OpenID-supporting site, since the site itself is agnostic with regards to the authentication method.
Briefly, it works like this: 1) You visit a website and type in your OpenID URL. 2) The web server fetches the URL and gets the OpenID server info from it. 3) It redirects your browser to the OpenID server. 4) You authenticate with the OpenID server. 5) The OpenID server redirects your browser back to whence it came, with some cryptographic info constructed from the authentication. 6) The original web server contacts the OpenID server to verify the info passed to it by the browser. 7) You're logged in! The scheme has some additional, optionally supportable optimizations as well, to decrease the number of HTTP roundtrips.
Of course, many here on Slashdot could probably set up their own OpenID server that has a unique identifier for each site, but how many do you think {are going to/are able to} do that -- especially among AOL users?
Actually, when using NetworkManager, the nm-applet, running as the user, will save the settings in the user's home directory. It connects to the main nm process (running as root) through the system d-bus, normally being authorized by pam_console. No prompts, and still perfectly secure.
Furthermore, I think it's kind of weird to say that it's "one processor". It may be one chip, but is a processor defined by its die? Since it's an 80-core chip, isn't it more accurate to say that it's 80 CPUs on one die, just as a dual-core chip is rather two CPUs on one die? It's not as if it isn't impressive, but I think it's kind of misleading to say that it's just one processor.
Quiet easily: It sucks just as much now as it did twenty years ago and every year thence. It's definitely not compilers getting worse, and although I don't know, I kind of doubt it ever was the programmers' fault that Windows is as it is.
[/specific rebuttals]
Anyway, my point was never that noone may ever, under any circumstances, need their own machine. I did mention kernel/driver work in my original post (although the ITS developers sure seemed to get things done even despite that), and although I was ignorant before your post (And happy! Damn you for destroying my pure innocent eyes! ;), I am hardly surprised that development under Windows has special requirements (Windows seems that have that effect on a great many things). My point, however, was that there almost seems to be a general stigma (I've seen it in many other places as well) that developers cannot timeshare a system, and considering how the vast majority of developers are very unlikely to require their own boxes for any of the reasons stated above, I didn't understand whence that stigma has come.
Care to explain for me? Is this, mayhap, some kind of Windows thing that I don't understand?
I most definitely disagree with you on that point. Except for things like bit-banging and polling, I think as much as possible should be done by the main processor. It usually only wastes a minimal amount of cycles anyway, and the advantage is that it is much easier to replace and fine-tune code to do exactly what you want it to do, rather than relying on pre-programmed or hardwired functionality in a peripheral. For example, if WiFi framing and RC4 encryption for WEP had been implemented in the driver instead of on the card, noone would need new cards to support WPA2 and AES -- just a driver update would have sufficed.
It isn't hard at all. Emacs has all these nifty functions where you can press M-C-(normal navigation keys) to move along balanced expressions, such as forward to the end of the current parenthesized expression in c-mode or back and forth s-exps in lisps. M-C-f for forward, M-C-b for backward M-C-u to go up one level, and, oh, M-C-DEL to delete one balanced expression backwards. Oops! I've done it several times.
Sure, I was probably just living in my own little world fabricated from stories on the web, but I was honestly surprised it was so low.
An interesting thing to know would be whether these reports are gathered from all over the world or just from North America. (Did TFA tell this? I hope noone expects me having read it. :) I would love seeing it if Microsoft decided to publish a detailed geographic report. :)
I may or may not agree with you, but I don't think that is the point of this whole article. Say that you have ~100 DRM:ed songs in your iTunes library, and then go to your nearest HiFi store and see, say, a nice Creative Zen MP3 player (well, it's not likely to be a Zune ;) that you think would be better than your iPod. Would you then be able to buy that Zen player and not having to spend $100+ on rebuying all your current music to go onto it?