Ethernet has pretty much completely taken over for LANs, but there are other LAN data-link layer protocols that could be used instead.
Here's the way I see it: HTTP would work with very little modification over IPX/SPX over token ring, but it would not be nearly so useful as it is without DNS. Besides HTTP this is also true for FTP, SMTP, POP3, IMAP, NNTP, Jabber, or whatever.
I just use a spreadsheet for that in OpenOffice. If your finances are so complex that you need special financial software because a spreadsheet can't handle entirely them, you seriously need to hire an accountant.
As far as dependency problems, yeah, that can be a real pain. The correct solution to this is static linking for everything but the core system libraries, but the open-source community is violently opposed to static linking, because it might (gasp) use up an extra two gigabytes of disk space per computer, in addition to freeing up tens of billions of system administrator man-hours worldwide.
Ugh, I forgot to mention Perl and Cygwin. Obviously no operating system can be in anything resembling a usable state without Perl installed, and Perl is not in a usable state without CPAN.pm working, which in Windows seems to require cygwin.
> It takes you ten hours to install a recent Linux distro? It should take > you less time than installing Windows XP.
He didn't say ten hours to install; he said ten hours to get it into a usable state. (Though, how he gets XP into a usable state in 3 hours is beyond me; it takes about 3 *days* last I checked, and I've reinstalled Windows quite a lot of times, and have a very good idea what I'm doing and a good ordered checklist. OTOH, I couldn't get a Linux system into what I consider a useable state in 10 hours either; maybe my standards for "usable state" are just higher than his.)
Getting a system into a usable state means configuring the internet settings, downloading and installing and configuring various things it might not come with out of the box, setting up your preferred applications to be the system default for this that and the other, configuring the preferences in all the major apps and in the OS and GUI, installing fonts, copying various data, testing all of the above, and assorted other tasks. On Windows this means you've got to install PowerTools (especially TweakUI), any of the corefonts that are missing (WHY aren't they always included? They're Microsoft's *own* core fonts!), a decent web browser (and maybe Java if you care), a decent text editor, a decent mail reader, an office suite, and a graphics editor, then configuring all of the above plus going through the control panel and the Windows Explorer options to ensure sanity, fixing up the registry associations for certain filetypes and protocols, downloading and installing the latest drivers from the manufacturers for any hardware that give you trouble (usually: the video card; frequently: the network card or modem; occasionally: any random other component, including possibly the PCI bridge or the ATAPI CD-ROM drive (I speak from experience)).
On Linux, getting the system into a usable state involves less downloading but more configuring. Usually you have to edit some of the config files, such as XF86-Config (e.g., if you have a PS/2 scrollmouse and want to be able to middle-click and scroll), wgetrc (if you are behind NAT, you probably need to use passive ftp), or fstab. The install process also asks you more configuration questions, and then you've got to configure things like xdm, in addition to your actual desktop environment and, of course, your applications. There is usually also some downloading: you'll want some fonts probably, and maybe Java, and although Perl will be installed, it usually doesn't have all the modules it should (such as WWW::Mechanize and DateTime), and Emacs, similarly, will have Gnus but may be missing other key components, such as eshell.
I don't know, off the top of my head, which system takes me longer to get into a usable state after a fresh install, but the timeframe is definitely measured in days, not hours, for both of them.
> How many people do you know that run Windows who haven't had some > terrible corruption issue from spyware, viruses, worms, etc?
I ran Windows for years and never had those problems. My family still runs Windows 98 on the PC in the living room -- I did have to run Ad-Aware on it *once* in the last several years. But, on my workstation I had to compile a new X server just as often in that same timeframe, and compiling an X server is significantly more involved than running Ad-Aware to clean off Gator. I also had to install new versions of GTK on numerous occasions, because the new version of some application required it -- in the most recent case, I had to do this twice in as many weeks, which annoyed me significantly more than needing to run Ad-Aware to clean off Gator. (I'm not going back to Windows, don't get me wrong. Windows annoys me too much with its lack of configurability and suboptimal UI that makes you minimize everything all the time just to get it out of the way, because you HAVE to get to the desktop, because MS couldn't bother to implement panel drawers or a decent CLI (though I hear the latter is coming in Longhorn, only about six years too late to stop me from switching). But my point is, it's easily possible for a clueful person to maintain a Windows desktop that's reasonably secure.)
The difference here is, my family's Win98 PC is atypical, because a clueful person administers it. So it has Pegasus Mail instead of Outlook Express, accesses the internet through a NAT gateway, doesn't have an IE shortcut on the desktop, has a registry merge running out of autoexec.bat to clean the IM out of the Run keys (so it only runs when someone actually clicks on its icon -- it's amazing how much more stable this makes the system), and so on. And this works with four clueless users using the thing -- when I used Windows (95 OSR2) myself, I didn't *need* a NAT gateway or registry merges to protect me or Ad-aware to clean up after me, because I didn't do foolish things. (Though with Windows XP the NAT would be a good idea even with only clueful user(s), due to the ports it opens.)
Linux is more secure than Windows on the whole, don't get me wrong, recent kernel news notwithstanding. But it's not as *much* more stable as you'd think by looking at the frequency of incidents, because, frankly, people who understand computers gravitate toward it (mostly for reasons that have nothing to do with security, although security can also be a factor), and people who understand computers maintain more secure systems on average.
What RMS doesn't understand is that some of us have lives, and familiarizing ourselves with the codebase of every piece of software we use is utterly and completely beyond the bounds of all reason. I use a lot of open-source software, for a variety of reasons -- it tends to be fairly configurable, which is important to me, tends to be of decent quality on the whole, and tends to be dirt cheap to obtain, which is important on my budget. But how many open source projects have I *actually* contributed anything useful to? I can count them on the fingers of one hand, even if I count filing quality bug reports as a useful contribution (which IMO it is, but definitely not quite the same as sending in patches). I've done bug reporting and testcase work for Mozilla, coded a proof of concept that gave rise to an Emacs module (though approximately 0% of the code in it now is from my original), and recently have made significant contributions to the Open Clip Art Library. But I only have so much time. I use lots of other software, that I *don't* have time to work on at all. In practice, even with the source code, I can't work on it. Not even if I wanted to. Under those circumstances, the "freedom" I gain by having the source code is marginal to nonexistant. The value I gain because *other* people who can contribute to it
> Is there ever a time when you can consider your systems secure against > an attacker with physical access?
In the phrase "local root exploit", the word "local" doesn't mean local in the sense of physically present, but in the sense of needing to already have user-level access. If you combine it with a non-root remote exploit, the two together add up to the equivalent of a remote root exploit.
In other words, this is definitely something we want to fix.
As far as securing a system against physical access, that's a whole nother kind of hard. At bare minimum you need an encrypted filesystem with a key that isn't stored and so has to be entered by an authorized user every time the filesystem is mounted, and then on top of that if you make sure that the machine, if left unattended, suspends running processes to disk and then unmounts the filesystem, and if you're both paranoid, obsessive, and tireless when it comes to bughunting, you potentially could develop a system that has a reasonable degree of security against an attacker with physical access -- but "a reasonable degree" does not mean "impenetrable" -- there are still hidden cameras, keyboard logging devices, and the like, to say nothing of rubber hose cryptanalysis.
I don't know the details of how it's done, but I know that junior high school students can open those things without the combination or any special tools. It's colloquially called "kicking locks", but, not having seen it done, I'm not certain actually kicking the lock is how it's done. Might be, though. Anyway, although I've not actually been present when it happened, I did have the lock on my locker kicked a couple of times. And don't say they watched me unlock it and got the combination, because if they'd watched me open the locker, they'd have known the latching mechanism on mine was broken and taking the lock off wasn't necessary. The first time it happened I found the lock locked onto one of the banister rungs on the stairwell (which was common; there were always half a dozen locks on different rungs there). The second time, I never found the lock.
And I don't think they fiddled around with turning the dial for twenty minutes, feeling friction and getting the combination, either, because my locker was directly across from the office, and we only had four minutes between classes.
> So is it chemistry or physics that makes this work?
It's actually mathematics.
Biology, when you break it down to the underlying principles that make it all work, is chemistry. Chemistry, when you break it down, is physics. Physics, when you break it down, is math. But then, fundamentally, art and philosophy and everything else are also math, ultimately, when you boil them down to it. But don't mind me, I just think everything is math because I majored in math.
> Funny you should mention, but those cheap master locks with the false gates > is absurdly easy to manipulate. As a locksmith... The longest one of these > has ever taken me is 20 minutes.
I find it interesting that a locksmith, of all people, thinks it could ever concievably take this long to open one of those things. Of course, it is your knowledge of the internals of the lock mechanism that is tripping you up. There are much faster ways to open those things than turning the dial, feeling friction, and deducing the combination. No, I don't mean bolt cutters. You can do it so that casual inspection and even use of the lock afterward will probably not discover what you've done, although the part of the lock that hooks onto the thingydoo inside gets worn out and the lock starts to feel very loose if you do it to the same lock too many times. If you still don't know what I'm talking about, no more hints: go find any eighth-grade boy whose favorite subjects are gym and study hall, hand him a locked $2 Master lock, and say, "I'll give you ten bucks if you can open this in under one minute with no tools except what you've got on you."
> Besides, I really, really doubt the abilities of an average American — > whose BMI is far off anything reasonable — to walk 20 km straight away.
I don't think the *average* American would have any trouble going 12 miles in 10 hours on foot, in an emergency. My BMI for example is doubtless rather higher than anyone who likes to use the term BMI will consider near reasonable, since I wear XL shirts and 38/34 pants, but come on, 12 miles in 10 hours is significantly less than two mph average. You could stop and rest for fifteen minutes after every fifteen minutes of walking and still make it with four hours to spare -- IF you leave everything and just go.
Granted, there are the elderly who don't have the calcium in their bones to walk more than a hundred yards in a day, and the disabled.
But in any event my point was that a lot of east-coast-dwelling Americans would NOT be willing to just pick up and leave.
> I have read there would be about 10 hours notice for the US. > And it will go 20 Kilometers inland. > couldn't that be handled on foot fairly reasonably?
Only if you leave everything behind and _go_. Keep in mind, this is the US eastern seaboard we're talking about.
> All this 'If you break it up, it doesn't help' is just nonsense. Especially > with a rock this size, which is about enough to flatten a fairly large city, > if I'm understanding this correctly. If it's going to hit, we probably won't > learn where exactly until the last approach, at which point it's too late > to evacuate Calcutta or wherever.
If it's large enough to flatten a large city, you don't want it to hit anywhere, not even in the middle of the Pacific.
However, 25 years is a long time; we can afford to just *watch* it for fifteen years, and that still leaves ten years more, *plenty* of time to alter its orbit if necessary so that it doesn't hit. (All this malarke about blowing it to pieces with nukes is just so much movie-plot nonsense. It would be much easier and safer to mount a few rockets on it and push it off course so it misses. Especially if we have several years to work out the details.)
Honestly, something that we see coming 25 years ahead of time isn't going to be scary unless it's *entirely* too large to move (i.e., sized more like a small planet than an asteroid), which seems unlikely -- and this little bitty thing isn't even close to that category. If you want to get yourself all worked up over the possibility of a large asteroid plowing into the Earth, think about one coming from a strange angle far out of the plane of the eccliptic so that we don't notice it until a few hours before it hits.
Depends how much SCO is willing to offer. Certainly, IBM isn't going to *give* SCO anything in a settlement, if that's what you mean, but they might be persuaded to call off their lawyers and forget the whole thing ever happened if SCO offers them enough. (I'm not sure what SCO has to offer, though. All their remaining material assets perhaps...)
> Yeah, right. Only an insignificant fraction of torrent traffic is legit.
This article is the first I'd heard of widespread illegal use of BitTorrent. I doubt if it's really all that many users; I suspect every thousand downloads or so of this type represents only one person (whereas, every thousand Mandrake ISO downloads represents several hundred people) -- i.e., the amount of traffic involved doesn't necessarily correlate with the number of users.
> You really think that the scheme will remain legal because of these few users?
No, I think (BitTorrent itself) will remain legal because it isn't really a very good system for copyright infringement. As the article notes if you read it, someone distributing an illegal movie or somesuch exposes himself to easy discovery for hours or even days, because the seed has to remain online until the first recipients have the whole file.
> BitTorrent and the likes will be shut down in 2005.
No, Suprnova and the likes will be shut down. BitTorrent will continue to be used by distributors of popular content to ease the load on their ftp servers.
Step 1: Get a Matrox card. Step 2: Install any operating system you want, any version, any distro.
I don't mean just relatively mainstream ones like Linux, either. Step 3: It Just Works. No, really, it actually does just work.
Seriously, Matrox cards are good stuff. They maybe don't have all the flashy features that excite the everything-must-be-overclocked-including-my-soundc ard crowd, but they're very solid, well-specified, and compatible with everything that will even think about running on PC hardware. Every time I've tried to use any other brand of graphics card (GeForce, NVidia, whatever), I've ended up regretting it. Display glitches and jumps, shoddy drivers, general flakiness... bah. I've NEVER had a problem with a Matrox card, EVER, unless you count that an old vintage-1998 Mystique doesn't do enough 3D acceleration to make recent 3D games happy (go figure).
> Blanket statements like this (and like "Goto is evil") do nothing to help > improve the quality of software as we know it. strcat() is not evil. Using > strcat on uncontrolled/unmonitored input on buffers whose memory allocation > we are unsure of IS.
No. The problem here (either way) is not what *functions* the programmer is using; the problem is what *language* the programmer is using. C was great in the 1970s, when computers filled whole rooms and needed every instruction per second that could be squeezed out of them. At the time, more robust languages (such as lisp) were just too darned slow, and if a feature required the computer to do a little too much (or waste too much storage), it just wasn't implemented. Word wrap was an optional _extra_ in word processing software, because it required the whole line to be (gasp) recopied while the user waited! C was great because it allowed programs that would otherwise have to be written in assembly language for efficiency reasons to be more portable -- and Unix directly benefitted from this, outstripping and leaving in the dust a number of otherwise better systems (TOPS-20 for example) that were unfortunately tied to specific hardware. Languages that allocated string space dynamically and did other things to coddle the programmer, such as lisp or BASIC, were only good for specific tasks where performance was less critical. The real VHLLs didn't even exist.
Today, there are still things that need to be written in a low-level language such as C. Device drivers are an excellent example. The performance and the efficiency really matter there. The kernel's scheduler is another example. But these things should be written by experienced programmers who know the heck what they're doing. (Yeah, I know, it doesn't always work out that way, and even experienced programmers still make mistakes...) But we still have every noob and his kid brother trying to write high-level applications in C for no good reason, and *this* is why we still have buffer overruns -- it's because we still have fixed-size buffers.
Will better languages eliminate all bugs? No. But they will, eventually, as they are gradually adopted, eliminate certain whole *classes* of bugs that have been plagueing us for 30+ years, buffer overruns being one of the most obvious. Pointer errors are another thing you don't have in VHLLs, because you don't have unsafe pointers or pointer arithmetic. (You can still make the mistake of treating a return value that may be undef as if it's definitely a reference, but the bug that results is easier to track down, because instead of happily writing bits into an unrelated piece of storage and possibly smashing something that will haunt you six hundred lines of code later it immediately complains that you can't use that value as a reference.) You don't get a fencepost error on the max value of an array index when you've replaced your legacy C-style for loops with foreach loops that don't use indices, for example. (Legacy for loops have been deprecated in Perl for virtually ever now, and in Perl6 they are going away completely; for will always mean foreach and will always operate on a list. The other VHLLs that haven't done this already will eventually.)
Your correct, cheaper code is still horribly needlessly long for what it accomplishes: with the brace style fixed for terseness and the superfluous blank lines removed, it still comes to seven lines (lines!), just to concatenate a couple of strings, which shouldn't take seven characters. And yes, I know it's a contrived example, but it's still illustrative.
> I think that most people would agree that if the program can be *easily* > removed from the underlying OS, it's not part of the OS itself. Therefore > I would not consider notepad.exe part of the OS,
Either you define "easily" differently than I do, or you've never attempted to delete notepad.exe from a WinXP system. It's not as difficult to exorcise as Outlook Express, but it's not as easy as dragging it to the Recycle Bin and emptying it, either.
For the purposes of vulnerabilities, I would consider something to be part of the core system if it provides an essential service, API, or whatnot that lots and lots of other libraries rely on. For example, I would consider GTK to be part of the core system, because every third application requires it (often a recent version of it, even), but I would not consider Firefox to be part of the core system, even though it's very popular, because little else relies on it. (Yeah, there's Gnusto and FireFTP and a couple of other extensions that are almost applications in their own right... but by that logic Gnusto could be a part of the core system since you can run IF games in it, and zbefunge (which you could run inside of Gnusto) could be part of the cores sytem, since you can run any small befunge application in it... but you've got to draw the line somewhere. It is a blurry line, though. Does Emacs count as part of the core system? Gnus, far from being a novelty like Gnusto, is a widely used and highly featureful application, probably the _most_ featureful mail/news client in existence for any platform, and there are a lot more Emacs modules like that than there are Firefox extensions... but if not Emacs, what about Python? Surely Perl is part of the core system; virtually nothing in a modern *nix distro works without Perl. So what about Python, then? There are a few apps that require it, though not as many as Java... The line is blurry.)
I managed to shave off a few strokes, getting it down to eight lines (at no more than 80 chars per line). I'm sure someone can do better, but here's what I've got so far:
$p=shift;$a=shift;i(shift);use Socket;socket S,PF_INET,SOCK_STREAM,6;bind S,&a($a);listen S,5;$/=$3;while(@ARGV&&($_="$p $a f".shift)||accept(C,S)&&($_= <C>)&&clo se C){m!^(.*?) (.*?) ([e-i])([^/]*)/(.*)$!s&&$1 eq$p&&&$3($2,$4,$5)}sub e{open F,">$_[1]";print F $_[2];close F}sub f{_($_,@_)for keys%k}sub g{open(F, "<$_[1]")&&_($_[0],$a,"e$_[1]",<F>);clo se F}sub h{_($_[0],$_,'i')for keys%k}sub i{$k{$_[0]}=1}sub a{$_[0]=~/^(.*):(\d+)$/&&$2>2e3&&sockaddr_in($2,in et_aton($1) )}sub _{socket X,PF_INET,SOCK_STREAM,6;$w=shift;if(connect X,a$w){print X "$p $_[0] $_[1]/$_[2]";close X}else{$k{$p}}=$7}
The word "shift" at five strokes is still in there four times, but it's not obvious how to improve on that. There are more things that can be done, though. For example, the if/else stuff can probably be converted to use the trinary... :... ?... operator, which usually saves strokes, and I'm almost sure at least one of those foreach loops could be made into a map, which also usually saves strokes. The Socket constants are also eating a few more strokes than is strictly necessary, and I'm virtually certain it's possible to reduce the number of variables by taking advantage of implicit $_ in a couple more cases... it ought to be possible to get this thing down to five lines, maybe four, and put it in an email signature.
Slashdot Mirror
> What about ethernet?
Ethernet has pretty much completely taken over for LANs, but there are
other LAN data-link layer protocols that could be used instead.
Here's the way I see it: HTTP would work with very little modification
over IPX/SPX over token ring, but it would not be nearly so useful as
it is without DNS. Besides HTTP this is also true for FTP, SMTP, POP3,
IMAP, NNTP, Jabber, or whatever.
> No "Microsoft Bob" on the list?
It got edged out by the Office Assistant.
TCP/IP isn't that big a deal. I mean, it's good, but there are other good
networking protocols. TCP/IP is just the one that caught on.
I'd consider DNS more important than TCP/IP.
> or the George Foreman Grilling Machine. Tough call...
You mean the USB iGrill?
> Uh, where's your financial package?
I just use a spreadsheet for that in OpenOffice. If your finances are so
complex that you need special financial software because a spreadsheet
can't handle entirely them, you seriously need to hire an accountant.
As far as dependency problems, yeah, that can be a real pain. The correct
solution to this is static linking for everything but the core system
libraries, but the open-source community is violently opposed to static
linking, because it might (gasp) use up an extra two gigabytes of disk
space per computer, in addition to freeing up tens of billions of system
administrator man-hours worldwide.
> On Windows this means [stuff]
Ugh, I forgot to mention Perl and Cygwin. Obviously no operating system can
be in anything resembling a usable state without Perl installed, and Perl is
not in a usable state without CPAN.pm working, which in Windows seems to
require cygwin.
> It takes you ten hours to install a recent Linux distro? It should take
> you less time than installing Windows XP.
He didn't say ten hours to install; he said ten hours to get it into a
usable state. (Though, how he gets XP into a usable state in 3 hours is
beyond me; it takes about 3 *days* last I checked, and I've reinstalled
Windows quite a lot of times, and have a very good idea what I'm doing
and a good ordered checklist. OTOH, I couldn't get a Linux system into
what I consider a useable state in 10 hours either; maybe my standards
for "usable state" are just higher than his.)
Getting a system into a usable state means configuring the internet settings,
downloading and installing and configuring various things it might not come
with out of the box, setting up your preferred applications to be the system
default for this that and the other, configuring the preferences in all the
major apps and in the OS and GUI, installing fonts, copying various data,
testing all of the above, and assorted other tasks. On Windows this means
you've got to install PowerTools (especially TweakUI), any of the corefonts
that are missing (WHY aren't they always included? They're Microsoft's
*own* core fonts!), a decent web browser (and maybe Java if you care), a
decent text editor, a decent mail reader, an office suite, and a graphics
editor, then configuring all of the above plus going through the control
panel and the Windows Explorer options to ensure sanity, fixing up the
registry associations for certain filetypes and protocols, downloading and
installing the latest drivers from the manufacturers for any hardware that
give you trouble (usually: the video card; frequently: the network card or
modem; occasionally: any random other component, including possibly the
PCI bridge or the ATAPI CD-ROM drive (I speak from experience)).
On Linux, getting the system into a usable state involves less downloading
but more configuring. Usually you have to edit some of the config files,
such as XF86-Config (e.g., if you have a PS/2 scrollmouse and want to be
able to middle-click and scroll), wgetrc (if you are behind NAT, you
probably need to use passive ftp), or fstab. The install process also
asks you more configuration questions, and then you've got to configure
things like xdm, in addition to your actual desktop environment and, of
course, your applications. There is usually also some downloading: you'll
want some fonts probably, and maybe Java, and although Perl will be
installed, it usually doesn't have all the modules it should (such as
WWW::Mechanize and DateTime), and Emacs, similarly, will have Gnus but
may be missing other key components, such as eshell.
I don't know, off the top of my head, which system takes me longer to get
into a usable state after a fresh install, but the timeframe is definitely
measured in days, not hours, for both of them.
> How many people do you know that run Windows who haven't had some
> terrible corruption issue from spyware, viruses, worms, etc?
I ran Windows for years and never had those problems. My family still runs
Windows 98 on the PC in the living room -- I did have to run Ad-Aware on it
*once* in the last several years. But, on my workstation I had to compile a
new X server just as often in that same timeframe, and compiling an X server
is significantly more involved than running Ad-Aware to clean off Gator. I
also had to install new versions of GTK on numerous occasions, because the
new version of some application required it -- in the most recent case, I
had to do this twice in as many weeks, which annoyed me significantly more
than needing to run Ad-Aware to clean off Gator. (I'm not going back to
Windows, don't get me wrong. Windows annoys me too much with its lack of
configurability and suboptimal UI that makes you minimize everything all
the time just to get it out of the way, because you HAVE to get to the
desktop, because MS couldn't bother to implement panel drawers or a decent
CLI (though I hear the latter is coming in Longhorn, only about six years
too late to stop me from switching). But my point is, it's easily possible
for a clueful person to maintain a Windows desktop that's reasonably secure.)
The difference here is, my family's Win98 PC is atypical, because a clueful
person administers it. So it has Pegasus Mail instead of Outlook Express,
accesses the internet through a NAT gateway, doesn't have an IE shortcut
on the desktop, has a registry merge running out of autoexec.bat to clean
the IM out of the Run keys (so it only runs when someone actually clicks
on its icon -- it's amazing how much more stable this makes the system),
and so on. And this works with four clueless users using the thing --
when I used Windows (95 OSR2) myself, I didn't *need* a NAT gateway or
registry merges to protect me or Ad-aware to clean up after me, because I
didn't do foolish things. (Though with Windows XP the NAT would be a good
idea even with only clueful user(s), due to the ports it opens.)
Linux is more secure than Windows on the whole, don't get me wrong, recent
kernel news notwithstanding. But it's not as *much* more stable as you'd
think by looking at the frequency of incidents, because, frankly, people
who understand computers gravitate toward it (mostly for reasons that have
nothing to do with security, although security can also be a factor), and
people who understand computers maintain more secure systems on average.
What RMS doesn't understand is that some of us have lives, and familiarizing
ourselves with the codebase of every piece of software we use is utterly and
completely beyond the bounds of all reason. I use a lot of open-source
software, for a variety of reasons -- it tends to be fairly configurable,
which is important to me, tends to be of decent quality on the whole, and
tends to be dirt cheap to obtain, which is important on my budget. But how
many open source projects have I *actually* contributed anything useful to?
I can count them on the fingers of one hand, even if I count filing quality
bug reports as a useful contribution (which IMO it is, but definitely not
quite the same as sending in patches). I've done bug reporting and testcase
work for Mozilla, coded a proof of concept that gave rise to an Emacs module
(though approximately 0% of the code in it now is from my original), and
recently have made significant contributions to the Open Clip Art Library.
But I only have so much time. I use lots of other software, that I *don't*
have time to work on at all. In practice, even with the source code, I
can't work on it. Not even if I wanted to. Under those circumstances, the
"freedom" I gain by having the source code is marginal to nonexistant. The
value I gain because *other* people who can contribute to it
> Is there ever a time when you can consider your systems secure against
> an attacker with physical access?
In the phrase "local root exploit", the word "local" doesn't mean local in
the sense of physically present, but in the sense of needing to already have
user-level access. If you combine it with a non-root remote exploit, the
two together add up to the equivalent of a remote root exploit.
In other words, this is definitely something we want to fix.
As far as securing a system against physical access, that's a whole nother
kind of hard. At bare minimum you need an encrypted filesystem with a key
that isn't stored and so has to be entered by an authorized user every time
the filesystem is mounted, and then on top of that if you make sure that the
machine, if left unattended, suspends running processes to disk and then
unmounts the filesystem, and if you're both paranoid, obsessive, and tireless
when it comes to bughunting, you potentially could develop a system that has
a reasonable degree of security against an attacker with physical access --
but "a reasonable degree" does not mean "impenetrable" -- there are still
hidden cameras, keyboard logging devices, and the like, to say nothing of
rubber hose cryptanalysis.
I don't know the details of how it's done, but I know that junior high school
students can open those things without the combination or any special tools.
It's colloquially called "kicking locks", but, not having seen it done, I'm
not certain actually kicking the lock is how it's done. Might be, though.
Anyway, although I've not actually been present when it happened, I did have
the lock on my locker kicked a couple of times. And don't say they watched
me unlock it and got the combination, because if they'd watched me open the
locker, they'd have known the latching mechanism on mine was broken and
taking the lock off wasn't necessary. The first time it happened I found
the lock locked onto one of the banister rungs on the stairwell (which was
common; there were always half a dozen locks on different rungs there).
The second time, I never found the lock.
And I don't think they fiddled around with turning the dial for twenty
minutes, feeling friction and getting the combination, either, because my
locker was directly across from the office, and we only had four minutes
between classes.
> So is it chemistry or physics that makes this work?
It's actually mathematics.
Biology, when you break it down to the underlying principles that make it all
work, is chemistry. Chemistry, when you break it down, is physics. Physics,
when you break it down, is math. But then, fundamentally, art and philosophy
and everything else are also math, ultimately, when you boil them down to it.
But don't mind me, I just think everything is math because I majored in math.
> Funny you should mention, but those cheap master locks with the false gates
> is absurdly easy to manipulate. As a locksmith... The longest one of these
> has ever taken me is 20 minutes.
I find it interesting that a locksmith, of all people, thinks it could ever
concievably take this long to open one of those things. Of course, it is
your knowledge of the internals of the lock mechanism that is tripping you
up. There are much faster ways to open those things than turning the dial,
feeling friction, and deducing the combination. No, I don't mean bolt
cutters. You can do it so that casual inspection and even use of the lock
afterward will probably not discover what you've done, although the part
of the lock that hooks onto the thingydoo inside gets worn out and the lock
starts to feel very loose if you do it to the same lock too many times.
If you still don't know what I'm talking about, no more hints: go find
any eighth-grade boy whose favorite subjects are gym and study hall, hand
him a locked $2 Master lock, and say, "I'll give you ten bucks if you can
open this in under one minute with no tools except what you've got on you."
> A real genius would set his combination to the LAST few digits of the
> Fibbonaci sequence
I prefer the last digits of the 42nd root of the base of the natural logarithm.
I use Acme::Eyedrops to create UML diagrams that are also the code!
(Okay, actually, I don't do that. But knowing it's possible is the closest
I come to UML.)
> Besides, I really, really doubt the abilities of an average American —
> whose BMI is far off anything reasonable — to walk 20 km straight away.
I don't think the *average* American would have any trouble going 12 miles
in 10 hours on foot, in an emergency. My BMI for example is doubtless rather
higher than anyone who likes to use the term BMI will consider near reasonable,
since I wear XL shirts and 38/34 pants, but come on, 12 miles in 10 hours is
significantly less than two mph average. You could stop and rest for fifteen
minutes after every fifteen minutes of walking and still make it with four
hours to spare -- IF you leave everything and just go.
Granted, there are the elderly who don't have the calcium in their bones to
walk more than a hundred yards in a day, and the disabled.
But in any event my point was that a lot of east-coast-dwelling Americans
would NOT be willing to just pick up and leave.
> I have read there would be about 10 hours notice for the US.
> And it will go 20 Kilometers inland.
> couldn't that be handled on foot fairly reasonably?
Only if you leave everything behind and _go_. Keep in mind, this is the US
eastern seaboard we're talking about.
> Of course, does anyone think New York could be evacuated in 10 hours?
10 hours? I'm not altogether certain the New York metropolitan area could
be evacuated in 10 days.
> All this 'If you break it up, it doesn't help' is just nonsense. Especially
> with a rock this size, which is about enough to flatten a fairly large city,
> if I'm understanding this correctly. If it's going to hit, we probably won't
> learn where exactly until the last approach, at which point it's too late
> to evacuate Calcutta or wherever.
If it's large enough to flatten a large city, you don't want it to hit
anywhere, not even in the middle of the Pacific.
However, 25 years is a long time; we can afford to just *watch* it for fifteen
years, and that still leaves ten years more, *plenty* of time to alter its
orbit if necessary so that it doesn't hit. (All this malarke about blowing
it to pieces with nukes is just so much movie-plot nonsense. It would be much
easier and safer to mount a few rockets on it and push it off course so it
misses. Especially if we have several years to work out the details.)
Honestly, something that we see coming 25 years ahead of time isn't going
to be scary unless it's *entirely* too large to move (i.e., sized more like
a small planet than an asteroid), which seems unlikely -- and this little
bitty thing isn't even close to that category. If you want to get yourself
all worked up over the possibility of a large asteroid plowing into the
Earth, think about one coming from a strange angle far out of the plane of
the eccliptic so that we don't notice it until a few hours before it hits.
> Settle? Does anyone see IBM settling?
Depends how much SCO is willing to offer. Certainly, IBM isn't going to
*give* SCO anything in a settlement, if that's what you mean, but they might
be persuaded to call off their lawyers and forget the whole thing ever
happened if SCO offers them enough. (I'm not sure what SCO has to offer,
though. All their remaining material assets perhaps...)
> Yeah, right. Only an insignificant fraction of torrent traffic is legit.
This article is the first I'd heard of widespread illegal use of BitTorrent.
I doubt if it's really all that many users; I suspect every thousand downloads
or so of this type represents only one person (whereas, every thousand Mandrake
ISO downloads represents several hundred people) -- i.e., the amount of traffic
involved doesn't necessarily correlate with the number of users.
> You really think that the scheme will remain legal because of these few users?
No, I think (BitTorrent itself) will remain legal because it isn't really a
very good system for copyright infringement. As the article notes if you read
it, someone distributing an illegal movie or somesuch exposes himself to easy
discovery for hours or even days, because the seed has to remain online until
the first recipients have the whole file.
> BitTorrent and the likes will be shut down in 2005.
No, Suprnova and the likes will be shut down. BitTorrent will continue to
be used by distributors of popular content to ease the load on their ftp
servers.
email consumes more bandwidth than you realize, certainly more than ftp.
Step 1: Get a Matrox card.
c ard
Step 2: Install any operating system you want, any version, any distro.
I don't mean just relatively mainstream ones like Linux, either.
Step 3: It Just Works. No, really, it actually does just work.
Seriously, Matrox cards are good stuff. They maybe don't have all the flashy
features that excite the everything-must-be-overclocked-including-my-sound
crowd, but they're very solid, well-specified, and compatible with everything
that will even think about running on PC hardware. Every time I've tried to
use any other brand of graphics card (GeForce, NVidia, whatever), I've ended
up regretting it. Display glitches and jumps, shoddy drivers, general
flakiness... bah. I've NEVER had a problem with a Matrox card, EVER, unless
you count that an old vintage-1998 Mystique doesn't do enough 3D acceleration
to make recent 3D games happy (go figure).
> Blanket statements like this (and like "Goto is evil") do nothing to help
> improve the quality of software as we know it. strcat() is not evil. Using
> strcat on uncontrolled/unmonitored input on buffers whose memory allocation
> we are unsure of IS.
No. The problem here (either way) is not what *functions* the programmer is
using; the problem is what *language* the programmer is using. C was great
in the 1970s, when computers filled whole rooms and needed every instruction
per second that could be squeezed out of them. At the time, more robust
languages (such as lisp) were just too darned slow, and if a feature required
the computer to do a little too much (or waste too much storage), it just
wasn't implemented. Word wrap was an optional _extra_ in word processing
software, because it required the whole line to be (gasp) recopied while the
user waited! C was great because it allowed programs that would otherwise
have to be written in assembly language for efficiency reasons to be more
portable -- and Unix directly benefitted from this, outstripping and leaving
in the dust a number of otherwise better systems (TOPS-20 for example) that
were unfortunately tied to specific hardware. Languages that allocated string
space dynamically and did other things to coddle the programmer, such as
lisp or BASIC, were only good for specific tasks where performance was less
critical. The real VHLLs didn't even exist.
Today, there are still things that need to be written in a low-level language
such as C. Device drivers are an excellent example. The performance and the
efficiency really matter there. The kernel's scheduler is another example.
But these things should be written by experienced programmers who know the
heck what they're doing. (Yeah, I know, it doesn't always work out that way,
and even experienced programmers still make mistakes...) But we still have
every noob and his kid brother trying to write high-level applications in C
for no good reason, and *this* is why we still have buffer overruns -- it's
because we still have fixed-size buffers.
Will better languages eliminate all bugs? No. But they will, eventually,
as they are gradually adopted, eliminate certain whole *classes* of bugs
that have been plagueing us for 30+ years, buffer overruns being one of the
most obvious. Pointer errors are another thing you don't have in VHLLs,
because you don't have unsafe pointers or pointer arithmetic. (You can still
make the mistake of treating a return value that may be undef as if it's
definitely a reference, but the bug that results is easier to track down,
because instead of happily writing bits into an unrelated piece of storage
and possibly smashing something that will haunt you six hundred lines of
code later it immediately complains that you can't use that value as a
reference.) You don't get a fencepost error on the max value of an array
index when you've replaced your legacy C-style for loops with foreach loops
that don't use indices, for example. (Legacy for loops have been deprecated
in Perl for virtually ever now, and in Perl6 they are going away completely;
for will always mean foreach and will always operate on a list. The other
VHLLs that haven't done this already will eventually.)
Your correct, cheaper code is still horribly needlessly long for what it
accomplishes: with the brace style fixed for terseness and the superfluous
blank lines removed, it still comes to seven lines (lines!), just to
concatenate a couple of strings, which shouldn't take seven characters.
And yes, I know it's a contrived example, but it's still illustrative.
> I think that most people would agree that if the program can be *easily*
> removed from the underlying OS, it's not part of the OS itself. Therefore
> I would not consider notepad.exe part of the OS,
Either you define "easily" differently than I do, or you've never attempted
to delete notepad.exe from a WinXP system. It's not as difficult to exorcise
as Outlook Express, but it's not as easy as dragging it to the Recycle Bin
and emptying it, either.
For the purposes of vulnerabilities, I would consider something to be part of
the core system if it provides an essential service, API, or whatnot that lots
and lots of other libraries rely on. For example, I would consider GTK to
be part of the core system, because every third application requires it (often
a recent version of it, even), but I would not consider Firefox to be part of
the core system, even though it's very popular, because little else relies on
it. (Yeah, there's Gnusto and FireFTP and a couple of other extensions that
are almost applications in their own right... but by that logic Gnusto could
be a part of the core system since you can run IF games in it, and zbefunge
(which you could run inside of Gnusto) could be part of the cores sytem, since
you can run any small befunge application in it... but you've got to draw
the line somewhere. It is a blurry line, though. Does Emacs count as part
of the core system? Gnus, far from being a novelty like Gnusto, is a widely
used and highly featureful application, probably the _most_ featureful
mail/news client in existence for any platform, and there are a lot more
Emacs modules like that than there are Firefox extensions... but if not
Emacs, what about Python? Surely Perl is part of the core system; virtually
nothing in a modern *nix distro works without Perl. So what about Python,
then? There are a few apps that require it, though not as many as Java...
The line is blurry.)
I managed to shave off a few strokes, getting it down to eight lines
o se F}sub h{_($_[0],$_,'i')for keys%k}subn et_aton($1)
... : ... ? ... operator, which usually saves strokes, and I'm
(at no more than 80 chars per line). I'm sure someone can do better,
but here's what I've got so far:
$p=shift;$a=shift;i(shift);use Socket;socket S,PF_INET,SOCK_STREAM,6;bind
S,&a($a);listen S,5;$/=$3;while(@ARGV&&($_="$p $a f".shift)||accept(C,S)&&($_=
<C>)&&clo se C){m!^(.*?) (.*?) ([e-i])([^/]*)/(.*)$!s&&$1 eq$p&&&$3($2,$4,$5)}sub
e{open F,">$_[1]";print F $_[2];close F}sub f{_($_,@_)for keys%k}sub g{open(F,
"<$_[1]")&&_($_[0],$a,"e$_[1]",<F>);cl
i{$k{$_[0]}=1}sub a{$_[0]=~/^(.*):(\d+)$/&&$2>2e3&&sockaddr_in($2,i
)}sub _{socket X,PF_INET,SOCK_STREAM,6;$w=shift;if(connect X,a$w){print X
"$p $_[0] $_[1]/$_[2]";close X}else{$k{$p}}=$7}
The word "shift" at five strokes is still in there four times, but it's not
obvious how to improve on that. There are more things that can be done,
though. For example, the if/else stuff can probably be converted to use
the trinary
almost sure at least one of those foreach loops could be made into a map,
which also usually saves strokes. The Socket constants are also eating
a few more strokes than is strictly necessary, and I'm virtually certain
it's possible to reduce the number of variables by taking advantage of
implicit $_ in a couple more cases... it ought to be possible to get this
thing down to five lines, maybe four, and put it in an email signature.