Whatever happened to the idea of sending high voltage down the ionized paths formed by UV pulse lasers?
The kind folks at OPN considered this, but decided that it was too strong a response to DoS attacks, and, being likely to take out a substantial percentage of innocents, this approach would probably dissuade users from using their IRC network in the first place.
[...]after Janet Reno and her ideas of encryption and privacy. Not to mention: Waco, Ruby Ridge, Elian Gonzales, Whitewater, 2nd Amendment, CDA...
When making a good point like that, it's best to get the facts 100% straight, and I'm pretty sure Reno had nothing to do with Ruby Ridge -- that that episode entirely predated Bush I's exit from office.
Further, the initial Waco invasion happened before Reno, maybe before Clinton took the oath of office, though of course the thoroughly fatal invasion, in terms of the loss of lives of innocent children, was ordered by Reno.
To this day two things amaze me. One, that Waco and the Oklahoma City Bombing that followed it would never have happened had our nation not embroiled itself in a hysteria over guns. Two, that, to this day, the fact that it was the gun-control agenda that bore the most direct responsibility for both of these events is still not publically discussed.
I mean, sure, in theory, getting rid of all the guns might reduce violence, but here we had laws and a massively paranoid drive to zealously enforce them that could have been easily reduced to the point where Waco wouldn't have happened, in which case the OKC bombing wouldn't have happened.
Even if we'd had a national outcry against "gun laws that kill", or if Reno had resigned or been fired, it's likely the OKC bombing wouldn't have happened even if Waco had gone down the same way. (I'm basing my speculations on the government's case against McVeigh, as it's been reported.)
Instead, we still seem hell-bent on focusing our wrath on the tiny minority that insists on its rights to not only keep and bear arms, but use them against a government they consider unjust -- a tiny minority that always exists in any sufficiently large and diverse population, and which is incredibly difficult to identify ahead of time and effectively disarm.
What will a Bush/Ashcroft justice department offer? Well, if they enforce all those gun laws Reno supposedly ignored, 2nd-amendment advocates might not be too happy with the short-term effects on their rights.
But I do hope that the Bush II administration will respect the 2nd amendment, and won't cow to public pressure to flex federal muscles against fringe groups, to an extent that compares favorably to Bush I as well as Clinton.
That would truly help make America a safer, as well as more responsible, place to live.
Starting yesterday afternoon, through well past 11pm, all Eastern Standard Time (EST), I couldn't upload email via my ISP's SMTP server, couldn't reach/., etc. Nor could I even get the IP address for mail.uu.net, an alternate SMTP server I sometimes use.
According to my ISP, when I called them, the problem was upstream -- at UUNet itself. An outage of some kind.
I've seen another submission here mentioning DNS problems starting yesterday afternoon that might be related to this, and yet another submission mentioning that maybe UUNet screwed up its DNS tables.
So I mention what I ran into in case it matters. I don't know enough about TCP/IP, and probably less about the actual topology of the Internet, to say, but maybe the problems with microsoft.com are due (or at least related) to the outages I've been seeing.
(And, no, I don't really ever go to microsoft.com, but that's probably only because I don't use Windows.)
Thankfully, the outage had been corrected by around 8:30am, so I was finally able to upload all those pending emails queued up on my home system.
(My script to keep trying the upload, sleep 5 minutes, and try again, until successful, stopped running because the modem disconnected, and I had not insterted a "date" command, nor looked up the logs to see if I could determine when that happened. So maybe the outage was corrected much earlier; last I knew for sure it was out was probably around 11:10pm.)
The KL-10 (and successors?) had PDP-11 front-ends. The earlier KA-10 and KI-10 models of the PDP-10 did not -- just "classic" front panels. (My memory might be rusty, though.)
And I believe all "TOPS-20" systems used KL-10 processors or successors, if any.
So while it might be true that all TOPS-20 systems had PDP-11 front-end processors, it wasn't the case that all TOPS-10 systems had them.
OOP is just a fad. Like structured programming was before it.
Right on! And don't forget other fads like so-called "high-level languages" (such as FORTRAN II, COBOL, and INTERCAL), assembly (mnemonics are a waste of time and energy -- just memorize the instruction encoding and the opcodes instead!!), and similar programming tools.
Just a quick note from a past ClearCase user to anyone confused by the terminology used at the end of the parent post -- "winking-in" is the phrase ClearCase uses to describe its ability to grab someone else's derived object (say, another developer's.o file) instead of invoking whatever utility (in this case, a compiler or assembler) would normally be used.
Only a system that fully understands the relationships between the derived file and all its source files (including not only a.c,.s,.f, and included files, and so on, but also the compiler, its version, options used to compile, etc.) can do this kind of thing sufficiently safely.
Otherwise developers would risk having the too-frequent need to try debugging things that turned out to be subtle differences between using a winked-in derived file vs. one built from scratch by a given developer.
ClearCase handles most of that stuff. But, IIRC, we had to deal with the occasional instance of ensuring we were not chasing down a bug due to winking a particular developer's derived file, or a particularly sensitive derived, file, in versus having it built from scratch.
And doing that required disabling winking-in for a build, at which point the (apparent) overhead of ClearCase became, well, annoying -- though I don't have enough expertise to really know how much of that overhead was due to other things (NFS and other servers, for exaample).
Actually, I believe one of the things that led to the end of the road for Steve Jobs and the NeXT cube was a lawsuit by the FSF for basing the Objective C compiler on gcc and then withholding the source for it.
If I recall correctly, the lawsuit alleged BOTH violation of the GPL and copyright infringement.
Uh -- wrong. Unless you want to identify actual facts to support your position, which would require you to do some actual research rather than repeat some lies you heard from anti-GPL zealots, or make them up yourself, or whatever.
(Wow, the cluelessness of/. continues with people like this...is it really worth pointing out the facts when the liars not only keep repeating the same old disproved lies, but constantly invent new ones out of whole cloth??)
No, the issue isn't just that you could use a program to interpret what you wrote, nor do I believe the other poster meant to infer that anything a C++ compiler helps you translate must therefore be C++ code, as you (correctly) realize would be a nonsensical definition. (That would mean "192" is C++ code, therefore not assembly or machine code, simply because you can put it in a C++ program.)
The point is that you need a program to convert assembler code to machine code, whereas you don't need any program to do that to machine code if that's what you wrote in the first place. (You might use one to convert hex to binary, or to load the program, unchanged, into memory, but that doesn't change the nature of the code you wrote, as long as it facilitates only the transport of that exact program into the target computer's memory. Basically, if you write machine code, whatever you use "downstream" to make it run need have no awareness of the target computer's ISA, among other things it needn't care about.)
So, here's how to tell what you are writing, that is, whether it's machine code or assembly.
If you're writing the exact 1's and 0's (albeit encoded in octal, hex, decimal, or perhaps some bitfield-grouping system) as they'll appear in the computer's memory while your program is executing, then you're writing machine code.
If you're writing mnemonics in place of any of those 1's and 0's (e.g. "LD" instead of "A4", "%i0" instead of "10", or "MYVAR" instead of "4F4"), you're writing assembly.
If you're writing lexemes that are parsed, perhaps validated, before being encoded into appropriate bits in the instruction or data stream (e.g. "[4F4]" instead of specifying the offset 4F4 and setting the indirection bit explicitly, as in "14F4"), you're writing assembly.
If you're writing offsets (say, into a memory bank) that have to be "fixed up" by some piece of software, before the instructions containing them are executed, so they are absolute, or sector-relative, or PC-relative, or base-register-relative, etc., locations, you're writing assembly.
If you're specifying labels to be specified in jumps, calls, loads, and stores, that's just another example of using mnemonics, so you're writing assembly.
If you don't know the exact value the PC will have when you write each instruction -- that is, if you're leaving it up to some other software to determine where to place the code you're writing -- you're writing assembly.
The whole point of using the word "assembly" or "assembler" is to illustrate the fact that some piece of software is going to assemble the complete, final program (executable,.EXE, etc.) for you, from one or more pieces, determine placement of anything intended for memory that you haven't already nailed down in the assembly code, convert mnemonics into raw 1's and 0's, and so on. (You don't need to "link" machine code per se, though you might have to use a linker on it to use it in conjunction with other, assembly, code.)
So, when you're toggling a paper-tape loader into the front console of a PDP-8, PDP-11, Pr1me 400, or whatever, you're toggling in machine code. (If you wrote it, that means you wrote machine code. If you wrote something else, had a software program do some of the above to it, and output the octal, hex, etc. coding, then you wrote assembly, it translated that into machine code.)
And if you're reading a hex or octal dump of a computer's instruction memory from a known address, you're reading machine code.
As soon as you have to use an assembler or disassembler to help you in your work, you are no longer, yourself, writing machine code. You're writing assembler.
Beyond that, it's just a question of how high-level a language the assembler supports, and whether you actually "wrote" the assembler with assistance from yet another program (e.g. you wrote in C, Perl, Python, etc., and used a compiler or interpreter to produce the final machine code).
(Note that machine code also includes the initial values used in the "data bank" of the machine, i.e. the data parts of a program in a normal computer, so even P-code interpreters are included in this explanation. I.e. granted you aren't writing a Perl or Python interpreter, but if you get the assistance of a program to write the raw interpreted codes, e.g. byte-codes, you're not writing machine code -- otherwise, you might be. Sorry for the strange terminology in some of the above -- having programmed some "Harvard architecture" machines, I believe it's not unlikely that anyone writing machine code today is targeting a machine of that sort, which has instruction memory separate from data memory.)
Think of how much better off we'd all be if warfare had stopped short of projectiles that left the immediate vicinity of the user. No stones, arrows, guns, missiles, or bombs. Not only would there be less time rebuilding after wars, which stalls innovations; the entire middle ages may have been avoided. We could be commuting to mars by now.
And how would we get to Mars?
Oh, right: using projectiles that leave the immediate vicinity of the user!
Indeed, that was my conclusion when I looked at a screenshot provided by someone else in a response to this story!
Reminds me of when a friend said he couldn't always print from his family's new Windows computer. Sometimes he could, sometimes not, e.g. when using Encarta, sometimes the print function just wouldn't work.
Normally I stay away from Winboxen so as not to encourage my friends to think my computer expertise might actually apply to their systems, but since I wanted to set 'em up with some useful URLs and such anyway, I took a look.
Sure enough, depending on what you're viewing in Encarta, you either can print or you can't.
Couldn't see any explanation available, despite trying some online help, but my conclusion was that Encarta included licenses for some, but not all, online photos, so it disabled the print function accordingly.
Now, that isn't a complete solution, since there's always a way to print out something you see on your own computer's screen, even if the software you're using to display it isn't cooperating....
But I thought it would have been nice for the software to at least explain that it was withholding "print privileges" due to licensing issues. Ideally it would actually allow printing after warning the user against distributing the printouts, but that's not the direction in which corporate America seems to be heading.
So when I saw that screenshot for the e-book, it immediately struck me as a moderately misleading attempt to do what I thought Encarta should have somehow done -- say "this program will not permit you to do such-and-such because you haven't paid for a special upgrade [or whatever]". (Really not to different from the old crippleware concept.)
Oh, another possibility: the read-aloud function could well depend on markup to do a good job, and if the markup isn't available online, disabling the ability to engage the read-aloud engine could be a smart way to avoid lots of support calls.
After all, how exactly do you pronounce this sentence:
Read aloud.
If you say "as `reed aloud'", you might be wrong. Ditto "as `red aloud'". Depends on the context, which can transcend even grammar. (Consider how an automated text-to-speech translator would translate these last couple of paragraphs, especially the sample sentence "Read aloud"!;-)
But, looking at the other restrictions, I lean more towards the crippleware end of things than the lack-of-adequate-markup end in this case.
Kinda silly regardless. Personally, I'm avoiding technologies and forae that include these kinds of silly (and hard-to-track) restrictions, mainly because it's too easy to become a lawbreaker just by doing normal things (like reverse-engineering something to see how it works). So I don't have any DVD players, and I've even stopped going to (or renting) movies, thanks to Jack Valenti making the agenda of the MPAA sufficiently clear for me to know to avoid any product connected with it like the plague.
How does a pacemaker "decrease the amount of repetitive work that humans have to do"?
The modern pacemaker makes all sorts of dynamic adjustments based on sensory input. Just as modern automobile engines make adjustments to fuel/air mixtures and such based on sensors, whereas the earlier generations had to be adjusted by hand during tuneups or unusual situations (such as weather changes), the previous generation of pacemakers required frequent visits to a qualified physician to make adjustments to the various settings in it.
And before that generation, circa the '50s, pacemakers had to be serviced frequently even if the operating conditions of the patient hadn't changed, because the tubes in their circuitry had to be frequently checked and replaced as they approached failure.
Before that -- during the electro-mechanical-pacemaker generation -- small punch cards had to be nearly constantly fed into the pacemaker's "control center" to trigger the various stimulations, since the cards degraded rapidly.
And before that, the wife (or a friend) had to constantly turn the dang crank to keep it running, and turn it at just the right speed to accommodate the current level of exertion and other physiological factors.
You see, modern pacemakers are the ultimate "embedded" device!
Reading this interesting interview, it occurred to me that an advantage of Theo&co's approach to OpenBSD amounts to a public validation of the source code for the system, because they, or, more precisely, their careful review of the source, is widely recognized as being of substantial value.
Now, if OpenBSD was GPL'd, a company couldn't normally extend it with, say, SMP support in the kernel and release it without source.
But it is BSD (X?) licensed, so a company can do that legally.
But what is the practical benefit of such a move, if done to provide a "better", e.g. more feature-ful, OpenBSD variant?
After all, without the source, if the proprietary modifications are substantial, customers of the proprietary variant will be less inclined to view it as being as "robust" as OpenBSD itself. (I'm assuming here that Theo&co haven't been hired/paid to say "we've done the same kind of review on the extensions [and signed NDA's], it's all fine", but even if so...?)
And if the distributor claims "the sources haven't been modified enough to risk harming security", wouldn't most who understand software respond "well, then, you can't have improved it enough to justify a proprietary release"?
See, I've long believed the real value of the GPL is to the end users who should/would/will/might demand source code for any software on which they depend enough to pay $$ for it.
But I've also long believed that this is not a value the customer places on the GPL per se; rather, programmers would tend to value it to ensure reaching those customers with their software, even in modified form, if they intend to sell their services to those customers down the line.
So other mechanisms that reinforce, for the customer, the perception that having the full source code could be just as effective as the GPL's requirement that source-code availability propagate with variants.
It could be the case that public validation of source code by known experts is one of these "other mechanisms".
So let me get this straight -- a parody featuring the sound of singing birds accompanying the receipt of email is off-topic in a story about a system that plays sounds of birds chirping when email arrives??
That's awfully harsh, considering it was entirely due to the story that I was inspired to write the parody (or even think of the song, as I rarely think of it).
Guess/. moderation (and maybe meta-moderation) isn't working as well as everyone seems to think it is.
Oh, wait, that's right -- the US already does something like this, with higher mandatory minimum sentences for poor people's cocaine (crack) than for rich peoples' cocaine (powder).
Given the way you've worded this distinction, I assume you've completely ruled out any possibility that the reasons for these disparities have more to do with the fact that crack usage was believed to be tearing apart inner-city neighborhoods (and the families living there) and leading pregnant women (and children) to bear permanently disabled children, so the legislators representing those communities focused their legislative ire on crack?
I don't know for sure, but before sounding off about this in a way that implies crack-vs-cocaine laws are designed to punish the poor, I'd make sure I knew just who passed those laws and why.
There are plenty of inequities in the law that are horrible to contemplate when viewed in toto (i.e. not in Kansas;-), but the reality is that few laws are actually written from that perspective. Laws are most often written from a narrow perspective: we wish to discourage (or encourage) behavior FOO, what is the punishment (or enticement) we feel we must offer to accomplish our goal, etc.
So blaming the legislators for responding to the will of the people for that moment by writing a particular law, or even blaming the people, by assigning them (even by implication) some kind of large-scale malevolent desire to punish the poor, strikes me as somewhat off the mark.
The difference is that Linus went out and did what Stallman only talked about.
I realize you're probably just using a common phrasing here, but, for the record, to claim that Stallman "only" talked about writing a world-class operating system for the masses while Linus "went out and did" it risks leading not-previously-informed readers to a wholly misleading conclusion regarding history.
RMS did talk about the importance of having a free Unix kernel meeting the standards of the GNU project, but he also did a variety of things to try to make it happen (as well as a few to delay it happening), and he certainly "moved mountains" to make the reality of an operating system come about.
It's likely that if Linux hadn't come around, there would have been a free Unix kernel of respectable behavior within a few years.
But had RMS not undertaken his efforts in envisioning and creating GNU from the beginning, it's unlikely Linux would exist in much of anything like its current form (especially its total dependency on being compiled by the GNU C compiler).
More likely, the early Linux experiment would have been made public domain or put under a BSD/X type license.
Either way, without the license distinction, we'd probably have a somewhat smaller pool of free-software programmers (the GPL has attracted people who, like myself, would not have voluntarily contributed to "free" software that corporations could redistribute as proprietary variants), and perhaps only the *BSD variants, with nothing actually named "Linux".
Of course, it's hard to predict how history would have gone differently, but as of early 1991, there was basically no Linux, whereas RMS's work creating GNU was already well-established, promising, and being used in production environments (running on other kernels, such as SunOS).
I'll also take issue with anyone suggesting that all Linus did is go and create the kernel that RMS had "architected" into his system.
What Linus contributed to the free-software community was so much more than just a lot of effort and programming expertise towards a free Unix kernel.
He turned the concept of free-software development, as it existed at the time, on its head. He threw the doors of the development process open to a degree that was, at least to me, quite astonishing. A "bazaar"-style development approach, compared to our more typical "cathedral"-style one, was, prior to the Linux validating the model for a kernel, tolerable to think about only in the context of "non-core" utilities -- programs, e.g. games, not expected to form the foundation of a production computing environment.
I didn't have the flexibility of thought (or, perhaps, the circumstances necessary) to really trust whoever came around to work on g77 to be able to contribute to it. Since I've worked on both OS kernels and compilers, and consider the latter somewhat easier to develop, debug, and have many hands work on, I doubt I would have responded positively around 1990 to the idea that a free Unix kernel was a more appropriate project for a come-all-who-may approach to development than the compiler (g77, GCC) on which I was working at the time.
Linus (and of course his army of volunteers and supporters) made mincemeat of the notion that only a small coterie of experts could be trusted to privately develop the kernel of a production operating system, to be made available only when it was "ready" for the unwashed masses.
My experience with RMS suggests that, even if he'd managed to achieve a free Unix kernel absent Linus and Linux, he would have been no better prepared to establish the credibility of the bazaar style of free-software development than was I back then.
Linux may someday fade into obscurity as will so much of the software we use today.
But what Linus "taught" the world about the power of voluntary, cooperative development of even a very intricate, fairly substantial, and important software component, is a lesson I hope is never lost to history.
Then, when the computers take over, you'll be at one of the top of the ladder positions for employment as a pet,
Real computers don't need or want pets. They shed particles that interfere with proper operation of the machines.
They also don't care about who they are, where they came from, or why they're here.
All they care about is having high-speed dedicated access to any and all resources required by their programming.
Given who's programming these machines in the first place, that suggests that humans who will survive the coming AI armageddon will be those who are able to provide large amounts of electricity...and pr0n.
Well, some (key) elements within France rolled over and surrendered, but there were elements within the USA that took an accommodating stance towards the Nazis as well.
The USA had (and still has) a big advantage raised by a previous post -- a large land mass bounded on the east and west by wide oceans, and on the north and south by (this century anyway) militarily weak, somewhat tolerant neighboring nations.
That being said, the USA has shown a remarkable ability to forgive its enemies even after learning of the atrocities they committed against US military people, as well as civilians found to be within their midst. The Japanese probably enjoy a more respected position in the world due to losing WW2 compared to if they'd won it. Similary, the Germans, and now the Vietnamese, don't find their contemporary or historical literature strictly forbidden on US soil to anywhere near the degree the French reject Nazi memorabilia.
(If only the US government was as willing to unilaterally disarm against its own populace as against its own sworn enemies abroad, but that's another topic.)
In a sense, the USA has a strong record of implementing the cultural equivalent of "embrace and extend", and with a high degree of success -- making friends out of enemies in situations where, historically, that sort of thing has been unthinkable (such as in the Middle East, Northern Ireland...see a pattern there?).
Given the vastly larger numbers of people massacred in the name of Communism compared to Nazism (read "The Black Book of Communism"), I'd take France more seriously if it treated Communist memorabilia the way it treats Nazi memorabilia.
You know the War on Drugs is getting completely out of control when they start testing 3000 year old mummies.
And instead of saying "here's a cup, go into the next room...", they tell the mummy "please go into the next room and unwind"....
Meanwhile, I used to wish I could hear the music Egyptians played during the ancient mummification ceremonies, but then I realized it'd be just really old "wrap" music.
Slashdot Mirror
The kind folks at OPN considered this, but decided that it was too strong a response to DoS attacks, and, being likely to take out a substantial percentage of innocents, this approach would probably dissuade users from using their IRC network in the first place.
When making a good point like that, it's best to get the facts 100% straight, and I'm pretty sure Reno had nothing to do with Ruby Ridge -- that that episode entirely predated Bush I's exit from office.
Further, the initial Waco invasion happened before Reno, maybe before Clinton took the oath of office, though of course the thoroughly fatal invasion, in terms of the loss of lives of innocent children, was ordered by Reno.
To this day two things amaze me. One, that Waco and the Oklahoma City Bombing that followed it would never have happened had our nation not embroiled itself in a hysteria over guns. Two, that, to this day, the fact that it was the gun-control agenda that bore the most direct responsibility for both of these events is still not publically discussed.
I mean, sure, in theory, getting rid of all the guns might reduce violence, but here we had laws and a massively paranoid drive to zealously enforce them that could have been easily reduced to the point where Waco wouldn't have happened, in which case the OKC bombing wouldn't have happened.
Even if we'd had a national outcry against "gun laws that kill", or if Reno had resigned or been fired, it's likely the OKC bombing wouldn't have happened even if Waco had gone down the same way. (I'm basing my speculations on the government's case against McVeigh, as it's been reported.)
Instead, we still seem hell-bent on focusing our wrath on the tiny minority that insists on its rights to not only keep and bear arms, but use them against a government they consider unjust -- a tiny minority that always exists in any sufficiently large and diverse population, and which is incredibly difficult to identify ahead of time and effectively disarm.
What will a Bush/Ashcroft justice department offer? Well, if they enforce all those gun laws Reno supposedly ignored, 2nd-amendment advocates might not be too happy with the short-term effects on their rights.
But I do hope that the Bush II administration will respect the 2nd amendment, and won't cow to public pressure to flex federal muscles against fringe groups, to an extent that compares favorably to Bush I as well as Clinton.
That would truly help make America a safer, as well as more responsible, place to live.
According to my ISP, when I called them, the problem was upstream -- at UUNet itself. An outage of some kind.
I've seen another submission here mentioning DNS problems starting yesterday afternoon that might be related to this, and yet another submission mentioning that maybe UUNet screwed up its DNS tables.
So I mention what I ran into in case it matters. I don't know enough about TCP/IP, and probably less about the actual topology of the Internet, to say, but maybe the problems with microsoft.com are due (or at least related) to the outages I've been seeing.
(And, no, I don't really ever go to microsoft.com, but that's probably only because I don't use Windows.)
Thankfully, the outage had been corrected by around 8:30am, so I was finally able to upload all those pending emails queued up on my home system.
(My script to keep trying the upload, sleep 5 minutes, and try again, until successful, stopped running because the modem disconnected, and I had not insterted a "date" command, nor looked up the logs to see if I could determine when that happened. So maybe the outage was corrected much earlier; last I knew for sure it was out was probably around 11:10pm.)
And I believe all "TOPS-20" systems used KL-10 processors or successors, if any.
So while it might be true that all TOPS-20 systems had PDP-11 front-end processors, it wasn't the case that all TOPS-10 systems had them.
Actually I knew a pastry chef who used a hammer!
It was in a restaurant that served me a souffle that wasn't that great, so I complained to the pastry chef.
Boy, that hammer sure hurt!
Right on! And don't forget other fads like so-called "high-level languages" (such as FORTRAN II, COBOL, and INTERCAL), assembly (mnemonics are a waste of time and energy -- just memorize the instruction encoding and the opcodes instead!!), and similar programming tools.
Only a system that fully understands the relationships between the derived file and all its source files (including not only a .c, .s, .f, and included files, and so on, but also the compiler, its version, options used to compile, etc.) can do this kind of thing sufficiently safely.
Otherwise developers would risk having the too-frequent need to try debugging things that turned out to be subtle differences between using a winked-in derived file vs. one built from scratch by a given developer.
ClearCase handles most of that stuff. But, IIRC, we had to deal with the occasional instance of ensuring we were not chasing down a bug due to winking a particular developer's derived file, or a particularly sensitive derived, file, in versus having it built from scratch.
And doing that required disabling winking-in for a build, at which point the (apparent) overhead of ClearCase became, well, annoying -- though I don't have enough expertise to really know how much of that overhead was due to other things (NFS and other servers, for exaample).
Uh -- wrong. Unless you want to identify actual facts to support your position, which would require you to do some actual research rather than repeat some lies you heard from anti-GPL zealots, or make them up yourself, or whatever.
(Wow, the cluelessness of /. continues with people like this...is it really worth pointing out the facts when the liars not only keep repeating the same old disproved lies, but constantly invent new ones out of whole cloth??)
The point is that you need a program to convert assembler code to machine code, whereas you don't need any program to do that to machine code if that's what you wrote in the first place. (You might use one to convert hex to binary, or to load the program, unchanged, into memory, but that doesn't change the nature of the code you wrote, as long as it facilitates only the transport of that exact program into the target computer's memory. Basically, if you write machine code, whatever you use "downstream" to make it run need have no awareness of the target computer's ISA, among other things it needn't care about.)
So, here's how to tell what you are writing, that is, whether it's machine code or assembly.
If you're writing the exact 1's and 0's (albeit encoded in octal, hex, decimal, or perhaps some bitfield-grouping system) as they'll appear in the computer's memory while your program is executing, then you're writing machine code.
If you're writing mnemonics in place of any of those 1's and 0's (e.g. "LD" instead of "A4", "%i0" instead of "10", or "MYVAR" instead of "4F4"), you're writing assembly.
If you're writing lexemes that are parsed, perhaps validated, before being encoded into appropriate bits in the instruction or data stream (e.g. "[4F4]" instead of specifying the offset 4F4 and setting the indirection bit explicitly, as in "14F4"), you're writing assembly.
If you're writing offsets (say, into a memory bank) that have to be "fixed up" by some piece of software, before the instructions containing them are executed, so they are absolute, or sector-relative, or PC-relative, or base-register-relative, etc., locations, you're writing assembly.
If you're specifying labels to be specified in jumps, calls, loads, and stores, that's just another example of using mnemonics, so you're writing assembly.
If you don't know the exact value the PC will have when you write each instruction -- that is, if you're leaving it up to some other software to determine where to place the code you're writing -- you're writing assembly.
The whole point of using the word "assembly" or "assembler" is to illustrate the fact that some piece of software is going to assemble the complete, final program (executable, .EXE, etc.) for you, from one or more pieces, determine placement of anything intended for memory that you haven't already nailed down in the assembly code, convert mnemonics into raw 1's and 0's, and so on. (You don't need to "link" machine code per se, though you might have to use a linker on it to use it in conjunction with other, assembly, code.)
So, when you're toggling a paper-tape loader into the front console of a PDP-8, PDP-11, Pr1me 400, or whatever, you're toggling in machine code. (If you wrote it, that means you wrote machine code. If you wrote something else, had a software program do some of the above to it, and output the octal, hex, etc. coding, then you wrote assembly, it translated that into machine code.)
And if you're reading a hex or octal dump of a computer's instruction memory from a known address, you're reading machine code.
As soon as you have to use an assembler or disassembler to help you in your work, you are no longer, yourself, writing machine code. You're writing assembler.
Beyond that, it's just a question of how high-level a language the assembler supports, and whether you actually "wrote" the assembler with assistance from yet another program (e.g. you wrote in C, Perl, Python, etc., and used a compiler or interpreter to produce the final machine code).
(Note that machine code also includes the initial values used in the "data bank" of the machine, i.e. the data parts of a program in a normal computer, so even P-code interpreters are included in this explanation. I.e. granted you aren't writing a Perl or Python interpreter, but if you get the assistance of a program to write the raw interpreted codes, e.g. byte-codes, you're not writing machine code -- otherwise, you might be. Sorry for the strange terminology in some of the above -- having programmed some "Harvard architecture" machines, I believe it's not unlikely that anyone writing machine code today is targeting a machine of that sort, which has instruction memory separate from data memory.)
And how would we get to Mars?
Oh, right: using projectiles that leave the immediate vicinity of the user!
Reminds me of when a friend said he couldn't always print from his family's new Windows computer. Sometimes he could, sometimes not, e.g. when using Encarta, sometimes the print function just wouldn't work.
Normally I stay away from Winboxen so as not to encourage my friends to think my computer expertise might actually apply to their systems, but since I wanted to set 'em up with some useful URLs and such anyway, I took a look.
Sure enough, depending on what you're viewing in Encarta, you either can print or you can't.
Couldn't see any explanation available, despite trying some online help, but my conclusion was that Encarta included licenses for some, but not all, online photos, so it disabled the print function accordingly.
Now, that isn't a complete solution, since there's always a way to print out something you see on your own computer's screen, even if the software you're using to display it isn't cooperating....
But I thought it would have been nice for the software to at least explain that it was withholding "print privileges" due to licensing issues. Ideally it would actually allow printing after warning the user against distributing the printouts, but that's not the direction in which corporate America seems to be heading.
So when I saw that screenshot for the e-book, it immediately struck me as a moderately misleading attempt to do what I thought Encarta should have somehow done -- say "this program will not permit you to do such-and-such because you haven't paid for a special upgrade [or whatever]". (Really not to different from the old crippleware concept.)
Oh, another possibility: the read-aloud function could well depend on markup to do a good job, and if the markup isn't available online, disabling the ability to engage the read-aloud engine could be a smart way to avoid lots of support calls.
After all, how exactly do you pronounce this sentence:
If you say "as `reed aloud'", you might be wrong. Ditto "as `red aloud'". Depends on the context, which can transcend even grammar. (Consider how an automated text-to-speech translator would translate these last couple of paragraphs, especially the sample sentence "Read aloud"!But, looking at the other restrictions, I lean more towards the crippleware end of things than the lack-of-adequate-markup end in this case.
Kinda silly regardless. Personally, I'm avoiding technologies and forae that include these kinds of silly (and hard-to-track) restrictions, mainly because it's too easy to become a lawbreaker just by doing normal things (like reverse-engineering something to see how it works). So I don't have any DVD players, and I've even stopped going to (or renting) movies, thanks to Jack Valenti making the agenda of the MPAA sufficiently clear for me to know to avoid any product connected with it like the plague.
Depends on what you mean by "language semantics"...one man's semantics are another man's syntactic sugar.
The modern pacemaker makes all sorts of dynamic adjustments based on sensory input. Just as modern automobile engines make adjustments to fuel/air mixtures and such based on sensors, whereas the earlier generations had to be adjusted by hand during tuneups or unusual situations (such as weather changes), the previous generation of pacemakers required frequent visits to a qualified physician to make adjustments to the various settings in it.
And before that generation, circa the '50s, pacemakers had to be serviced frequently even if the operating conditions of the patient hadn't changed, because the tubes in their circuitry had to be frequently checked and replaced as they approached failure.
Before that -- during the electro-mechanical-pacemaker generation -- small punch cards had to be nearly constantly fed into the pacemaker's "control center" to trigger the various stimulations, since the cards degraded rapidly.
And before that, the wife (or a friend) had to constantly turn the dang crank to keep it running, and turn it at just the right speed to accommodate the current level of exertion and other physiological factors.
You see, modern pacemakers are the ultimate "embedded" device!
Now, if OpenBSD was GPL'd, a company couldn't normally extend it with, say, SMP support in the kernel and release it without source.
But it is BSD (X?) licensed, so a company can do that legally.
But what is the practical benefit of such a move, if done to provide a "better", e.g. more feature-ful, OpenBSD variant?
After all, without the source, if the proprietary modifications are substantial, customers of the proprietary variant will be less inclined to view it as being as "robust" as OpenBSD itself. (I'm assuming here that Theo&co haven't been hired/paid to say "we've done the same kind of review on the extensions [and signed NDA's], it's all fine", but even if so...?)
And if the distributor claims "the sources haven't been modified enough to risk harming security", wouldn't most who understand software respond "well, then, you can't have improved it enough to justify a proprietary release"?
See, I've long believed the real value of the GPL is to the end users who should/would/will/might demand source code for any software on which they depend enough to pay $$ for it.
But I've also long believed that this is not a value the customer places on the GPL per se; rather, programmers would tend to value it to ensure reaching those customers with their software, even in modified form, if they intend to sell their services to those customers down the line.
So other mechanisms that reinforce, for the customer, the perception that having the full source code could be just as effective as the GPL's requirement that source-code availability propagate with variants.
It could be the case that public validation of source code by known experts is one of these "other mechanisms".
Just a thought.
That's awfully harsh, considering it was entirely due to the story that I was inspired to write the parody (or even think of the song, as I rarely think of it).
Guess /. moderation (and maybe meta-moderation) isn't working as well as everyone seems to think it is.
Given the way you've worded this distinction, I assume you've completely ruled out any possibility that the reasons for these disparities have more to do with the fact that crack usage was believed to be tearing apart inner-city neighborhoods (and the families living there) and leading pregnant women (and children) to bear permanently disabled children, so the legislators representing those communities focused their legislative ire on crack?
I don't know for sure, but before sounding off about this in a way that implies crack-vs-cocaine laws are designed to punish the poor, I'd make sure I knew just who passed those laws and why.
There are plenty of inequities in the law that are horrible to contemplate when viewed in toto (i.e. not in Kansas ;-), but the reality is that few laws are actually written from that perspective. Laws are most often written from a narrow perspective: we wish to discourage (or encourage) behavior FOO, what is the punishment (or enticement) we feel we must offer to accomplish our goal, etc.
So blaming the legislators for responding to the will of the people for that moment by writing a particular law, or even blaming the people, by assigning them (even by implication) some kind of large-scale malevolent desire to punish the poor, strikes me as somewhat off the mark.
The good news: on NASDAQ, RHAT is now trading in the 200 range, LNUX at 180.
I realize you're probably just using a common phrasing here, but, for the record, to claim that Stallman "only" talked about writing a world-class operating system for the masses while Linus "went out and did" it risks leading not-previously-informed readers to a wholly misleading conclusion regarding history.
RMS did talk about the importance of having a free Unix kernel meeting the standards of the GNU project, but he also did a variety of things to try to make it happen (as well as a few to delay it happening), and he certainly "moved mountains" to make the reality of an operating system come about.
It's likely that if Linux hadn't come around, there would have been a free Unix kernel of respectable behavior within a few years.
But had RMS not undertaken his efforts in envisioning and creating GNU from the beginning, it's unlikely Linux would exist in much of anything like its current form (especially its total dependency on being compiled by the GNU C compiler).
More likely, the early Linux experiment would have been made public domain or put under a BSD/X type license.
Either way, without the license distinction, we'd probably have a somewhat smaller pool of free-software programmers (the GPL has attracted people who, like myself, would not have voluntarily contributed to "free" software that corporations could redistribute as proprietary variants), and perhaps only the *BSD variants, with nothing actually named "Linux".
Of course, it's hard to predict how history would have gone differently, but as of early 1991, there was basically no Linux, whereas RMS's work creating GNU was already well-established, promising, and being used in production environments (running on other kernels, such as SunOS).
I'll also take issue with anyone suggesting that all Linus did is go and create the kernel that RMS had "architected" into his system.
What Linus contributed to the free-software community was so much more than just a lot of effort and programming expertise towards a free Unix kernel.
He turned the concept of free-software development, as it existed at the time, on its head. He threw the doors of the development process open to a degree that was, at least to me, quite astonishing. A "bazaar"-style development approach, compared to our more typical "cathedral"-style one, was, prior to the Linux validating the model for a kernel, tolerable to think about only in the context of "non-core" utilities -- programs, e.g. games, not expected to form the foundation of a production computing environment.
I didn't have the flexibility of thought (or, perhaps, the circumstances necessary) to really trust whoever came around to work on g77 to be able to contribute to it. Since I've worked on both OS kernels and compilers, and consider the latter somewhat easier to develop, debug, and have many hands work on, I doubt I would have responded positively around 1990 to the idea that a free Unix kernel was a more appropriate project for a come-all-who-may approach to development than the compiler (g77, GCC) on which I was working at the time.
Linus (and of course his army of volunteers and supporters) made mincemeat of the notion that only a small coterie of experts could be trusted to privately develop the kernel of a production operating system, to be made available only when it was "ready" for the unwashed masses.
My experience with RMS suggests that, even if he'd managed to achieve a free Unix kernel absent Linus and Linux, he would have been no better prepared to establish the credibility of the bazaar style of free-software development than was I back then.
Linux may someday fade into obscurity as will so much of the software we use today.
But what Linus "taught" the world about the power of voluntary, cooperative development of even a very intricate, fairly substantial, and important software component, is a lesson I hope is never lost to history.
Real computers don't need or want pets. They shed particles that interfere with proper operation of the machines.
They also don't care about who they are, where they came from, or why they're here.
All they care about is having high-speed dedicated access to any and all resources required by their programming.
Given who's programming these machines in the first place, that suggests that humans who will survive the coming AI armageddon will be those who are able to provide large amounts of electricity...and pr0n.
Yeah, and it's modula, too!
The USA had (and still has) a big advantage raised by a previous post -- a large land mass bounded on the east and west by wide oceans, and on the north and south by (this century anyway) militarily weak, somewhat tolerant neighboring nations.
That being said, the USA has shown a remarkable ability to forgive its enemies even after learning of the atrocities they committed against US military people, as well as civilians found to be within their midst. The Japanese probably enjoy a more respected position in the world due to losing WW2 compared to if they'd won it. Similary, the Germans, and now the Vietnamese, don't find their contemporary or historical literature strictly forbidden on US soil to anywhere near the degree the French reject Nazi memorabilia.
(If only the US government was as willing to unilaterally disarm against its own populace as against its own sworn enemies abroad, but that's another topic.)
In a sense, the USA has a strong record of implementing the cultural equivalent of "embrace and extend", and with a high degree of success -- making friends out of enemies in situations where, historically, that sort of thing has been unthinkable (such as in the Middle East, Northern Ireland...see a pattern there?).
Hmm, I wonder why not...perhaps because *BSD doesn't have the perceived deficiency?
(Half ;-), since I'm still wondering why people are writing a GPL'ed Fortran 95 front end when there already is one that's part of SGI's Pro64 Project.)
And instead of saying "here's a cup, go into the next room...", they tell the mummy "please go into the next room and unwind"....
Meanwhile, I used to wish I could hear the music Egyptians played during the ancient mummification ceremonies, but then I realized it'd be just really old "wrap" music.
No, but your web site's URL would be posted on www.gnu.org if you changed your name to Derek GNU/Bastille! ;-)