Now, if only the number of users who downloaded and installed it made a commercial difference to the company, that'd matter.
What really matters from the point of view of these companies, though, is what distros people buy "enterprise" variants of, pay for the customisation and deployment of, and pay for support on. That's where these people make their money. I doubt that area has much correlation at all with what people are doing with small edge servers and their desktops.
Simple. I don't have the time; even if I did, I should be spending it on more important things than building my own server OS from scratch. That becomes doubly so when maintaining a bunch of servers (I run four Linux servers currently).
Essentially, that's why there are Linux distros. Installing a Linux-based OS used to be very much as you describe - but distros like Yggdrasil appeared because that was *painful*. Sure, with faster computers now it's probably less painful (glibc sure hasn't grown apace with CPU speed, for example) but I'm still not convinced it's generally a good idea.
In addition to time, there's the small matter of security. Doing things the way you suggest means a lot of watching mailing lists for security alerts, upgrading bits of your servers in a hurry, etc. Distros are good not only at doing the watching for issues for you, but they even do the hard work of providing the fixes in a nice, won't-break-your-system form. I rather like this.
That's not to say there's not a time and a place for rolling your own OS from OSS components, just that I don't think it's a good idea for a production server. I've done it before - making a tiny uclibc based image to netboot machines with as part of an image-based installer - but it's not something I like to do if I can find a faster, simpler way.
The effect you mention can be achieved almost as well by dragging in the very stripped down core of a distro like Debian and building your apps on top of it. I used to maintain rather a lot of local builds of apps (Cyrus IMAPd and PostgreSQL in particular) but even for them I'm increasingly trying to just use packaged versions. One less thing to waste time on.
Linux: Restart the email program, it crashed *again*. Windows: Restart the OS, the email program crashed for the first time in the year you've been using it. Mac: The email program can't crash, you have to find a good one first.
What doesn't "just work" is posting on Slashdot. Surely there must be an option to change the default post format from "pure evil" to "plain text" somewhere...
I too am amazed by what some Linux zealots are willing to call good. I've seen some such people recommend new users who just want a working desktop try out Gentoo. Because compiling your own OS on your ancient PC is fun! Yay!
Riight.
Barring bad advice from total morons, I'm surprised you've had that much trouble. Even with older distros it should be pretty easy to get a desktop that "just works" rather smoothly - probably as of RH8 or so. There is the issue of hardware support though - if you have certain classes of troublesome hardware (including some common ones like software modems), then yes it can be a total PITA and probably not worth it unless you have a resident guru.
Frankly, I find all the systems I run "just work": <ul> <li>The NT4 server <li>The Linux servers <li>The SCO OpenServer box (though I have to run a cron job to restart it's lpd daily) <li>The Win9x desktops <li>The WinXP desktops <li>The Linux thin client desktops (they're more trouble than the WinXP boxes though TBH) <li>My home and work Linux desktops <li>The MacOS/X machines (more trouble than both XP and Linux here, but that's partly because we need classic apps and need to talk to ancient networks) </ul>
Actually, everything except our MacOS/9 machines "just work". The MacOS/9 machines seem to soak up all the problems from everything else and deliver them in an un-ending stream of crashes and misery.
With good hardware and some basic knowledge about the OS you're working on (Windows, Linux, OS/X, whatever) you should get pretty good results these days. Even MacOS/9 can be reliable if you don't hook it up to a network, are extremely careful about font selection, and don't run QuarkXPress.
I can't say I've had that sort unfortunate experience, so I'd be interested to know which distro you're using and what 3rd party packages.
My own experience is that the vast majority of crashes in both Windows and Linux come down to bad hardware. The balance seem to be mostly crappy drivers, with a dose of spyware and virii thrown in for Windows and a shot of crap 3rd party packages for Linux.
My own experience has been fairly positive with Fedora Core (1 & 3), Debian (Sarge, Woody, and before that Potato) and Red Hat (6.2 -> 9), all of which I've run or admined systems with at various points. I've also had very good results with Win2k (my Win2k install eventually broke utterly, but it was my fault - I stopped a service I thought was unimportant and COM/ActiveX stopped working. There doesn't seem to be any coming back from that) and WinXP, when carefully operated.
As of win2k (and NT4, but really... who used that on workstations?) Windows does seem acceptably solid. I find it reasonably reliable if I'm very careful to stick to quality apps and restrict what the user can do (e.g. MSIE set to a proxy that always rejects and "allowed" sites in no-proxy list; max security settings except for "trusted sites"; user can't install software - even browser plug-ins.).
The real problems seem to arrive with desktops where software has been added and removed over time, less-than-ideal quality software has been installed, etc. The OS is still much too easily broken by crappy 3rd party software. If you avoid that, you should be fine.
Careful use of XP's features like System Restore can further improve things.
I still think it's pretty sad just how much vigilance and skill must be applied to keep a Windows box running reliably, but it's easier than it used to be. The Win9x boxes at work seem to go insane after a couple of years no matter what I do.
While I generally agree with your views, I can't entirely agree on the matter of developers. In my view, in the context of the Debian distribution, a "developer" has quite a different set of required skills.
A Debian developer - think "person who develops packages for Debian" - needs to be able to work with the Debian packaging system, needs to know quite a bit about porting apps to different archs, and needs to be a build system wizard. They don't need to know how to write a linked list in C - but they might need to know how to correctly replace all str[something-weird]* calls with another flavour or fix assumptions in the upstream source that cause a dependence on Solaris's libc.
I know quite a few very good developers who could't make a package for any distro to save their life. I also know quite a few skilled package maintainers whose ability to fix others' code is often astonishing despite their relative lack of traditional programming expertise. I also know a fair few people (myself included) who think that if you're implementing a linked list, you need to get over your NIH syndrome and discover the wonder of libraries, and/or get a higher-level language;-)
Overall - I'm not convinced "Debian developer" is the best title, when "package maintainer" is often more accurate, but many of these folks deserve the term Developer as much as whoever hacks out the original package.
Ah, drat - you're an AC anyway. May as well post this given that I've already written it.
There's one option you probably had with your server but you haven't covered here - network backups at the co-lo site. They're not perfect (if the colo facility burns down, you're screwed) but a heck of a lot better than nothing.
I currently do network backups of the whole system to storage at the colo provider (I'd do monthly tapes, but they don't have a DLT or LTO tape drive). I do network backups of the server's configuration every week. I do network backups of the server's criticial, fast-changing data (CVS repositories, mainly) to local dated snapshots every day.
Admittedly I do have a 1.5TB server at work where I can stash the snapshots, but failing that one could use an ageing scheme.
Until recently I would've agreed with you on the matter of servers (running Debian stable for a desktop is IMO utterly hopeless).
My view recently changed when I realised that most of the system I was operating was from backports.org not Debian stable. To get some of the basics I needed I was having to go out to 3rd party repositories - ones with no guarantee of security support.
I agree with your view about ABI compatibility, but as a developer also understand why. That constant breaking of compatibility is one of the reasons open source software can develop so fast. Having to worry about working around a bugs and limitations in older versions of libtiff or libxml would be yet another slowdown. It's quite possible to install multiple versions of libraries in parallel, too, thanks to the soname versioning scheme in *nix, though few distributors package more than one version of a library.
It's not just ABI compatibility too, though, it's compatibility with "old bugs" and with API changes.
To be honest, it sounds a lot like what you want is FreeBSD. I've been tempted to try it out for similar reasons myself - dead stable, small "OS", easily upgraded extra userspace. That's pretty much what I want - like having "woody" for the core OS, but "sarge" for the rest, w/o the nightmares that entails when you try to do it on Debian (IMHO it's impressive they've made it work at all).
Backports could satisfy the same role - the "ports" collection in fbsd - but it doesn't seem to have all that much coverage or all that much enthusiasm behind it.
A requirement for a valid URL seems reasonable. Thus:
smb://hostname/path
as used by some browsers.
More to the point, a browser needs access to the file system, and on Windows \\unc\paths are as much a part of "the file system" as D:\drive\letter\based\paths are.
Consider OpenSSL. OpenSSL is a Linux operating system; however it is a fairly independent library implemented using only public APIs. Many parts of "the operating system" depend on OpenSSL and would break upon its removal.
Ditto MSIE.
IE uses public APIs from the OS. Other parts of the OS use public APIs of IE. Thus IE cannot be removed from the OS without removing or altering the components that depent on it - such as, AFAIK, Windows Explorer (the file manager).
We can question the decision to make other parts o f the OS depend so deeply on IE, and we can question the decision to make that dependency on IE rather than an abstract "web browser API" that could be implemented by other tools. That doesn't change the fact that it's still a part of the OS.
Most of your points I agree with, especially re NAT being harmful to the 'net. I think ISPs rather like NAT for exactly that reason - it makes NAT'd users "good little Internet consumers" whose ability to fully participate as a provider and a "consumer" on the 'net is somewhat crippled.
I don't really agree re weak typing, though. It's not really weak typing that's at issue, it's that memory management is still done "by hand". Most of the nasty overflows stem from the fact that C lets you copy a 200 char long buffer into (and over the end of) a char[20]. There are other related issues, but I don't think weak typing is one of them. Weak typing is dumb, yes, but I think manual memory management is the real culprit.
Also, while ISPs can't track down all the compromised machines, some simple steps can massively reduce the damage:
Block port 25 by default, except to their SMTP servers. (Users should still be permitted to open it).
Block common RPC ports, incoming AND outgoing, by default. This means SMB/CIFS, portmap, etc.
Impose network blocks on ports used by major worm outbreaks as they appear, again giving the user the option to disable the block.
My ISP does all of this, and more. It's really only the responsible thing to do, and I don't expect it costs them a large amount of time. The biggest cost is probably slightly smarter and more powerful routers.
Well, NAT might be a good thing in that it's a simple "security" step that _currently_ helps protect users against _some_ threats.
Alas, it does really break the way the 'net works - hosting your own services can be a screaming nightmare over NAT. With static IP addresses, always-on 'net connections, and things like MacOS/X's Apache-based "personal web sharing", that's no longer just the preserve of the hard-core geek.
I'm with the parent poster to your post in most regards. I'm also still hopeful that we'll see IPv6 start to take the worst of the weight off soon (now that 6to4 permits it to be adopted in cells anywhere on the 'net).
There's also the matter of Windows boxes, until very recently, running with internet-exposed services by default. RPC services, no less.
How many UNIX admins do you know of that don't flinch in horror at the thought or leaving an RPC service - think portmap - exposed to the Internet?
Of course, lately MS has been improving this situation at a great rate. Linux distros have been doing so more slowly, and commercial UNIXes remain a joke (telnet and NFS on by default and exposed to the internet, etc).
That said, I tend to agree... MS is more careless with keeping track of 'tainted' inputs, trusted data, and the distinction between data and executable code than pretty much anybody else. I guess they're paying for it.
Are you sure that wasn't a local reaction to the vaccination? Some vaccines cause a rather nasty local reaction that'll leave a scar, skin damage, etc. IIRC the Smallpox vaccine was big on that.
It's much easier than that. Any sort of VPN will work fine - for example, SSH port forwarding.
A workmate spent a year in China, and did this routinely so he could access non-filtered searches. He also used our IMAP and SMTP server over an SSH tunnel, since his ISP didn't even _provide_ an SMTP server. Apparently "email" is hotmail.com in China.
While all this worked fine... I'm not entirely sure I'd want to be doing it as a native Chinese resident. Being the guy who always encrypts his traffic might not be the smartest thing in the world over there. Perhaps that's unreasonably paranoid.
If I recall correctly, at least at some points the Celeron has been a P2/P3/P4 with failed cache turned off.
I think the same may have been true of the Duron - an Athlon with bad cache that's disabled, and/or one that won't run at the full Athlon bus speed.
I *know* it's something LCD manufacturers do (in the sense that every LCD panel is cut from a "faulty" sheet in such a way as to minimise the number of faults on it), and I'm pretty sure RAM manufacturers do this as well.
After all, *ALL* CPUs fit this pattern in at least one way - clock speed. AMD don't go and make 2GHz Athlon XPs, 2.2GHz versions, etc. They make "Athlon XPs", test them, and sell them at the clock speeds they're capable of running reliably at. My understanding is that the yield curve is also a major factor in the pricing "slope" of CPUs.
This sort of thing is simply sensible business, and I'd be surprised if it wasn't widespread in many other non-safety-critical areas too.
The only code I have to work with that's like that is a jungle of pseudo-OO spaghetti, full of 500-line-long case statements and loops. It's horrifying.
I've never yet been happy with my own code when control structures end up nested more than about 4 levels deep, except sometimes in _extremely_ localised blocks.
My personal view is that two-space indents encourage excessively deep nesting. It's just too easy to nest conditional structures and loops very deeply without your code looking too contorted at a glance.
Of course, that's the viewpoint of someone who doesn't use two-space indenting;-)
I'll use whatever the code I'm working on uses reasonably comfortably though. I currently regularly work on code with: <ul> <li>4-spaces-indenting with a tabstop of 8</li> <li>4-spaces-indenting with a tabstop of 4</li> <li>4-spaces expanded indenting</li> </ul>... and work with other indenting schemes when doing quick fixes to less familar code. Big deal - it doesn't seem to matter that much if your editor doesn't suck.
My own code is usually 4-space-expanded for Python code, 4-tabstop for C++, and 4-space-8-tabstop for Java. Those those are the conventions followed by the code I work with most in each language, and they work OK for me.
The only language I even understand why people care strongly about indenting in is Python (where I maintain that unexpanded tabs are madness).
I try to as well, but I'm pretty sure neither of us succeed. Why? Because far too many protocol designers think their protocol is "special" and "more important" so they implement a fallback to tunnelling over HTTP (port 80, even over a proxy).
Unless you have a *very* smart transparent HTTP proxy, there go a lot of your RPC blocks. SOAP seems particularly vile in this respect.
Regarding "real mice," let's just say I'm a little scarred by those puck things;-) . Man am I glad those are gone...
Frankly, I'd be very surprised if Apple chose to release a mouse that wasn't a stanard USB HID device with the normal buttons. They're pretty good about that sort of thing these days. I guess they might do something like detect it by device ID and select different default behaviour though...
While I personally find the lack very frustrating (and get annoyed by "new" Linux apps that fail to support it - grr) I've actually spent a lot of time finding out how to turn it off for my users.
Lots of them simply can't scroll without clicking. They scroll around emails and word processing docs, pasting random crap everywhere. It's terrifying.
I eventually ended up remapping the middle mouse button to a non-existent button using xmodmap in their.xsession scripts, since *NOTHING* appears to let you disable this behaviour without disabling the button.
In fact, if you a real mouse into a MacOS/X box it already works that way. The wheel works out of the box too. Almost like all the developers use proper mice;-)
Slashdot Mirror
Now, if only the number of users who downloaded and installed it made a commercial difference to the company, that'd matter.
What really matters from the point of view of these companies, though, is what distros people buy "enterprise" variants of, pay for the customisation and deployment of, and pay for support on. That's where these people make their money. I doubt that area has much correlation at all with what people are doing with small edge servers and their desktops.
Simple. I don't have the time; even if I did, I should be spending it on more important things than building my own server OS from scratch. That becomes doubly so when maintaining a bunch of servers (I run four Linux servers currently).
Essentially, that's why there are Linux distros. Installing a Linux-based OS used to be very much as you describe - but distros like Yggdrasil appeared because that was *painful*. Sure, with faster computers now it's probably less painful (glibc sure hasn't grown apace with CPU speed, for example) but I'm still not convinced it's generally a good idea.
In addition to time, there's the small matter of security. Doing things the way you suggest means a lot of watching mailing lists for security alerts, upgrading bits of your servers in a hurry, etc. Distros are good not only at doing the watching for issues for you, but they even do the hard work of providing the fixes in a nice, won't-break-your-system form. I rather like this.
That's not to say there's not a time and a place for rolling your own OS from OSS components, just that I don't think it's a good idea for a production server. I've done it before - making a tiny uclibc based image to netboot machines with as part of an image-based installer - but it's not something I like to do if I can find a faster, simpler way.
The effect you mention can be achieved almost as well by dragging in the very stripped down core of a distro like Debian and building your apps on top of it. I used to maintain rather a lot of local builds of apps (Cyrus IMAPd and PostgreSQL in particular) but even for them I'm increasingly trying to just use packaged versions. One less thing to waste time on.
Linux: Restart the email program, it crashed *again*.
Windows: Restart the OS, the email program crashed for the first time in the year you've been using it.
Mac: The email program can't crash, you have to find a good one first.
Arrggh!
What doesn't "just work" is posting on Slashdot. Surely there must be an option to change the default post format from "pure evil" to "plain text" somewhere...
I too am amazed by what some Linux zealots are willing to call good. I've seen some such people recommend new users who just want a working desktop try out Gentoo. Because compiling your own OS on your ancient PC is fun! Yay!
Riight.
Barring bad advice from total morons, I'm surprised you've had that much trouble. Even with older distros it should be pretty easy to get a desktop that "just works" rather smoothly - probably as of RH8 or so. There is the issue of hardware support though - if you have certain classes of troublesome hardware (including some common ones like software modems), then yes it can be a total PITA and probably not worth it unless you have a resident guru.
Frankly, I find all the systems I run "just work":
<ul>
<li>The NT4 server
<li>The Linux servers
<li>The SCO OpenServer box (though I have to run a cron job to restart it's lpd daily)
<li>The Win9x desktops
<li>The WinXP desktops
<li>The Linux thin client desktops (they're more trouble than the WinXP boxes though TBH)
<li>My home and work Linux desktops
<li>The MacOS/X machines (more trouble than both XP and Linux here, but that's partly because we need classic apps and need to talk to ancient networks)
</ul>
Actually, everything except our MacOS/9 machines "just work". The MacOS/9 machines seem to soak up all the problems from everything else and deliver them in an un-ending stream of crashes and misery.
With good hardware and some basic knowledge about the OS you're working on (Windows, Linux, OS/X, whatever) you should get pretty good results these days. Even MacOS/9 can be reliable if you don't hook it up to a network, are extremely careful about font selection, and don't run QuarkXPress.
I can't say I've had that sort unfortunate experience, so I'd be interested to know which distro you're using and what 3rd party packages.
My own experience is that the vast majority of crashes in both Windows and Linux come down to bad hardware. The balance seem to be mostly crappy drivers, with a dose of spyware and virii thrown in for Windows and a shot of crap 3rd party packages for Linux.
My own experience has been fairly positive with Fedora Core (1 & 3), Debian (Sarge, Woody, and before that Potato) and Red Hat (6.2 -> 9), all of which I've run or admined systems with at various points. I've also had very good results with Win2k (my Win2k install eventually broke utterly, but it was my fault - I stopped a service I thought was unimportant and COM/ActiveX stopped working. There doesn't seem to be any coming back from that) and WinXP, when carefully operated.
As of win2k (and NT4, but really ... who used that on workstations?) Windows does seem acceptably solid. I find it reasonably reliable if I'm very careful to stick to quality apps and restrict what the user can do (e.g. MSIE set to a proxy that always rejects and "allowed" sites in no-proxy list; max security settings except for "trusted sites"; user can't install software - even browser plug-ins.).
The real problems seem to arrive with desktops where software has been added and removed over time, less-than-ideal quality software has been installed, etc. The OS is still much too easily broken by crappy 3rd party software. If you avoid that, you should be fine.
Careful use of XP's features like System Restore can further improve things.
I still think it's pretty sad just how much vigilance and skill must be applied to keep a Windows box running reliably, but it's easier than it used to be. The Win9x boxes at work seem to go insane after a couple of years no matter what I do.
While I generally agree with your views, I can't entirely agree on the matter of developers. In my view, in the context of the Debian distribution, a "developer" has quite a different set of required skills.
;-)
A Debian developer - think "person who develops packages for Debian" - needs to be able to work with the Debian packaging system, needs to know quite a bit about porting apps to different archs, and needs to be a build system wizard. They don't need to know how to write a linked list in C - but they might need to know how to correctly replace all str[something-weird]* calls with another flavour or fix assumptions in the upstream source that cause a dependence on Solaris's libc.
I know quite a few very good developers who could't make a package for any distro to save their life. I also know quite a few skilled package maintainers whose ability to fix others' code is often astonishing despite their relative lack of traditional programming expertise. I also know a fair few people (myself included) who think that if you're implementing a linked list, you need to get over your NIH syndrome and discover the wonder of libraries, and/or get a higher-level language
Overall - I'm not convinced "Debian developer" is the best title, when "package maintainer" is often more accurate, but many of these folks deserve the term Developer as much as whoever hacks out the original package.
Ah, drat - you're an AC anyway. May as well post this given that I've already written it.
There's one option you probably had with your server but you haven't covered here - network backups at the co-lo site. They're not perfect (if the colo facility burns down, you're screwed) but a heck of a lot better than nothing.
I currently do network backups of the whole system to storage at the colo provider (I'd do monthly tapes, but they don't have a DLT or LTO tape drive). I do network backups of the server's configuration every week. I do network backups of the server's criticial, fast-changing data (CVS repositories, mainly) to local dated snapshots every day.
Admittedly I do have a 1.5TB server at work where I can stash the snapshots, but failing that one could use an ageing scheme.
--
Craig Ringer
Until recently I would've agreed with you on the matter of servers (running Debian stable for a desktop is IMO utterly hopeless).
My view recently changed when I realised that most of the system I was operating was from backports.org not Debian stable. To get some of the basics I needed I was having to go out to 3rd party repositories - ones with no guarantee of security support.
I agree with your view about ABI compatibility, but as a developer also understand why. That constant breaking of compatibility is one of the reasons open source software can develop so fast. Having to worry about working around a bugs and limitations in older versions of libtiff or libxml would be yet another slowdown. It's quite possible to install multiple versions of libraries in parallel, too, thanks to the soname versioning scheme in *nix, though few distributors package more than one version of a library.
It's not just ABI compatibility too, though, it's compatibility with "old bugs" and with API changes.
To be honest, it sounds a lot like what you want is FreeBSD. I've been tempted to try it out for similar reasons myself - dead stable, small "OS", easily upgraded extra userspace. That's pretty much what I want - like having "woody" for the core OS, but "sarge" for the rest, w/o the nightmares that entails when you try to do it on Debian (IMHO it's impressive they've made it work at all).
Backports could satisfy the same role - the "ports" collection in fbsd - but it doesn't seem to have all that much coverage or all that much enthusiasm behind it.
A requirement for a valid URL seems reasonable. Thus:
smb://hostname/path
as used by some browsers.
More to the point, a browser needs access to the file system, and on Windows \\unc\paths are as much a part of "the file system" as D:\drive\letter\based\paths are.
Consider OpenSSL. OpenSSL is a Linux operating system; however it is a fairly independent library implemented using only public APIs. Many parts of "the operating system" depend on OpenSSL and would break upon its removal.
Ditto MSIE.
IE uses public APIs from the OS. Other parts of the OS use public APIs of IE. Thus IE cannot be removed from the OS without removing or altering the components that depent on it - such as, AFAIK, Windows Explorer (the file manager).
We can question the decision to make other parts o f the OS depend so deeply on IE, and we can question the decision to make that dependency on IE rather than an abstract "web browser API" that could be implemented by other tools. That doesn't change the fact that it's still a part of the OS.
I don't really agree re weak typing, though. It's not really weak typing that's at issue, it's that memory management is still done "by hand". Most of the nasty overflows stem from the fact that C lets you copy a 200 char long buffer into (and over the end of) a char[20]. There are other related issues, but I don't think weak typing is one of them. Weak typing is dumb, yes, but I think manual memory management is the real culprit.
Also, while ISPs can't track down all the compromised machines, some simple steps can massively reduce the damage:
My ISP does all of this, and more. It's really only the responsible thing to do, and I don't expect it costs them a large amount of time. The biggest cost is probably slightly smarter and more powerful routers.
Well, NAT might be a good thing in that it's a simple "security" step that _currently_ helps protect users against _some_ threats.
Alas, it does really break the way the 'net works - hosting your own services can be a screaming nightmare over NAT. With static IP addresses, always-on 'net connections, and things like MacOS/X's Apache-based "personal web sharing", that's no longer just the preserve of the hard-core geek.
I'm with the parent poster to your post in most regards. I'm also still hopeful that we'll see IPv6 start to take the worst of the weight off soon (now that 6to4 permits it to be adopted in cells anywhere on the 'net).
There's also the matter of Windows boxes, until very recently, running with internet-exposed services by default. RPC services, no less.
... MS is more careless with keeping track of 'tainted' inputs, trusted data, and the distinction between data and executable code than pretty much anybody else. I guess they're paying for it.
How many UNIX admins do you know of that don't flinch in horror at the thought or leaving an RPC service - think portmap - exposed to the Internet?
Of course, lately MS has been improving this situation at a great rate. Linux distros have been doing so more slowly, and commercial UNIXes remain a joke (telnet and NFS on by default and exposed to the internet, etc).
That said, I tend to agree
Are you sure that wasn't a local reaction to the vaccination? Some vaccines cause a rather nasty local reaction that'll leave a scar, skin damage, etc. IIRC the Smallpox vaccine was big on that.
It's much easier than that. Any sort of VPN will work fine - for example, SSH port forwarding.
... I'm not entirely sure I'd want to be doing it as a native Chinese resident. Being the guy who always encrypts his traffic might not be the smartest thing in the world over there. Perhaps that's unreasonably paranoid.
A workmate spent a year in China, and did this routinely so he could access non-filtered searches. He also used our IMAP and SMTP server over an SSH tunnel, since his ISP didn't even _provide_ an SMTP server. Apparently "email" is hotmail.com in China.
While all this worked fine
That's pretty standard even now.
If I recall correctly, at least at some points the Celeron has been a P2/P3/P4 with failed cache turned off.
I think the same may have been true of the Duron - an Athlon with bad cache that's disabled, and/or one that won't run at the full Athlon bus speed.
I *know* it's something LCD manufacturers do (in the sense that every LCD panel is cut from a "faulty" sheet in such a way as to minimise the number of faults on it), and I'm pretty sure RAM manufacturers do this as well.
After all, *ALL* CPUs fit this pattern in at least one way - clock speed. AMD don't go and make 2GHz Athlon XPs, 2.2GHz versions, etc. They make "Athlon XPs", test them, and sell them at the clock speeds they're capable of running reliably at. My understanding is that the yield curve is also a major factor in the pricing "slope" of CPUs.
This sort of thing is simply sensible business, and I'd be surprised if it wasn't widespread in many other non-safety-critical areas too.
Nested 5 and 7 levels deep?
Eek.
The only code I have to work with that's like that is a jungle of pseudo-OO spaghetti, full of 500-line-long case statements and loops. It's horrifying.
I've never yet been happy with my own code when control structures end up nested more than about 4 levels deep, except sometimes in _extremely_ localised blocks.
My personal view is that two-space indents encourage excessively deep nesting. It's just too easy to nest conditional structures and loops very deeply without your code looking too contorted at a glance.
;-)
... and work with other indenting schemes when doing quick fixes to less familar code. Big deal - it doesn't seem to matter that much if your editor doesn't suck.
Of course, that's the viewpoint of someone who doesn't use two-space indenting
I'll use whatever the code I'm working on uses reasonably comfortably though. I currently regularly work on code with:
<ul>
<li>4-spaces-indenting with a tabstop of 8</li>
<li>4-spaces-indenting with a tabstop of 4</li>
<li>4-spaces expanded indenting</li>
</ul>
My own code is usually 4-space-expanded for Python code, 4-tabstop for C++, and 4-space-8-tabstop for Java. Those those are the conventions followed by the code I work with most in each language, and they work OK for me.
The only language I even understand why people care strongly about indenting in is Python (where I maintain that unexpanded tabs are madness).
"We come in peace"
Dammit, now I have to go play Starcon 2 again...
I try to as well, but I'm pretty sure neither of us succeed. Why? Because far too many protocol designers think their protocol is "special" and "more important" so they implement a fallback to tunnelling over HTTP (port 80, even over a proxy).
Unless you have a *very* smart transparent HTTP proxy, there go a lot of your RPC blocks. SOAP seems particularly vile in this respect.
Regarding "real mice," let's just say I'm a little scarred by those puck things ;-) . Man am I glad those are gone...
Frankly, I'd be very surprised if Apple chose to release a mouse that wasn't a stanard USB HID device with the normal buttons. They're pretty good about that sort of thing these days. I guess they might do something like detect it by device ID and select different default behaviour though...
While I personally find the lack very frustrating (and get annoyed by "new" Linux apps that fail to support it - grr) I've actually spent a lot of time finding out how to turn it off for my users.
.xsession scripts, since *NOTHING* appears to let you disable this behaviour without disabling the button.
Lots of them simply can't scroll without clicking. They scroll around emails and word processing docs, pasting random crap everywhere. It's terrifying.
I eventually ended up remapping the middle mouse button to a non-existent button using xmodmap in their
In fact, if you a real mouse into a MacOS/X box it already works that way. The wheel works out of the box too. Almost like all the developers use proper mice ;-)