If you're trying to remember a command you've run before you can run this to find it quickly.
history | grep 'command'
If you're using bash or zsh with the default emacs-like bindings, you can use ctrl-r to do an interactive backwards search in your history. Just keep hitting ctrl-r to search deeper back into the history.
Also, the one thing I've noted a lot of intermediate Linux users don't know about, but find very useful upon investigation is job control. Even with good window management and multiple xterms, job control is very useful: I often have three or four jobs on each xterm. Also, a neat trick: with zsh or bash, "fg %-" goes back to the second-to-last job. You can use this to quickly suspend and switch between two jobs continuously (eg, after you've done it once, "ctrl-z, ctrl-p, enter" switches to the "other" job).
Also, if there's a long command I recently executed, I usually won't search through history, but rather use the "!cmd" thing. Eg, if you've recently run "gcc -g -Wall -O3 -blahblah..." a few commands ago, you can do it again by just typing "!gc" without searching. I guess it's really a question of preference, but I picked this up from the older gurus who were weaned on the monstrosity which is the C shell.
I use zsh on all my non-Linux machines and just use the default bash on all my Linux boxes. First of all, I have one common.zshrc and.bashrc which all my machines get. The last line sources.zsh-local or.bash-local, where I keep all my machine-specific settings. This way, when I think of something clever to put in.zshrc, I can distribute it to all my machines at once.
Here are some stupid shell tricks I've found moderately useful:
bash: HISTCONTROL=ignoreboth, zsh: setopt HIST_IGNORE_SPACE;
This means when you type a command with a space in front of it, it doesn't go in your history. Useful if you do something that you don't want others to see (eg, xv ~/.pr0n/*.jpg).
The zsh FAQ has an entry which describes how to get your xterm title to describe all sorts of fun stuff. Here's a bash equivalent:
# see the document/xc/doc/hardcopy/xterm/ctlseqs.PS.gz # on any XFree86 mirror; the only other cool thing you # can do is change the font with "ESC ] 5 0 ; fontname BEL" xtitle() { echo -ne "\033]2;$*\007" >/dev/tty } if [ "$TERM" = "xterm" -o "$TERM" = "xterm-color" ] ; then PROMPT_COMMAND="echo -ne '\017'" fi if [ "$TERM" = "xterm" \ -o "$TERM" = "xterm-color" \ -o "$TERM" = "rxvt" \ -o "$TERM" = "cygwin" ] ; then settitle() { xtitle "`date +'%H:%M:%S'` - ${HOSTESS}: $PWD" } PROMPT_COMMAND="settitle ; $PROMPT_COMMAND" fi
PATH management:
pathdel() { PATH=`echo $PATH | sed -e "s/\(.*\)\(\:\)$1\(\:\)\(.*\)/\1:\4/g" \ -e "s/^$1://" -e "s/:$1\$//"` } pathadd() { if echo $PATH | fgrep "$1" >/dev/null 2>&1 ; then : else if [ -d $1 ] ; then case $2 in "append") PATH=$PATH:$1;; "prepend") PATH=$1:$PATH;; *) echo fixme;; esac fi fi }
pathdel '\.'
if [ "$UID" -eq "0" ] ; then pathadd/sbin "append" pathadd/usr/sbin "append" pathadd/usr/local/sbin "append" for i in/usr/local/*/sbin ; do pathadd $i "append" ; done for i in/opt/*/sbin ; do pathadd $i "append" ; done fi
This next one is absolutely necessary on any Linux machine:
alias kilmoz='killall -9 netscape ; rm -f ~/.netscape/lock'
Recursively do something for each subdirectory:
dirs() { # follows symlinks, prints dot-dirs ls -A $@ | while read i ; do [ -d $i ] && echo $i ; done } recurse() { # DFS dirs | while read DIR ; do $@ cd $DIR recurse $@ cd.. done }
Here's a dumb shell script that I call "randsort" - it prints out lines from stdin in a random order:
This is useful 'cause you can do something like this:
xv `ls -t ~/.pr0n/*.jpg | head -200 | randsort`
and this randomization, for some reason, "feels" better than xv's -random option. It also has a number of "legitimate" uses. For instance:
playm3u() { randsort < $1 | while read i ; do mpg123 "$i" ; done # heh - 'mpg123 -z --list "$i"' does same thing nowadays }
Anyway, I got lots of stupid little crap like this. I try not to get too far into the customization stuff, as it's definitely a timesink and it's very important to be able to use a "standard" unix setup. For example, my.emacs is circa 80 KB (I'm big into Lisp), but I'm extremely proficient with vi, because there are lots of situations where emacs is not available, or vi is better-suited to the job.
The lameness filter is such a piece of horseshit. I mean, are the editors deliberately trying to prevent us from discussing code and technical matters? You'll need to re-indent all the snippets above because of this.
Lameness filter fodder:
C este un limbaj de programare cu scop general ale carui caracteristici sint economia de expresie, structuri moderne de control al fluxului si de date, precum si un set bogat de operatori. C nu este un limbaj de nivel "foarte inalt", nici "mare", si nu este specializat vreunei arii particulare de aplicatii. Dar absenta in restrictii si generalitatea sa il fac mai convenabil si mai de efect pentru mai multe scopuri decit limbaje presupuse mai puternice. C a fost la inceput proiectat si implementat pe sistemul de operare UNIX pe DEC PDP11 de catre Dennis Ritchie. Sistemul de operare, compilatorul C si in mod esential, toate programele de aplicatii ale lui UNIX (inclusiv software-ul folosit pentru a pregati cartea aceasta) sint scrise in C. Compilatoare de C exista deasemenea si pe mai multe alte calculatoare, intre care IBM System/370 Honeywell 6000 si Interdata 8/32. C nu este legat de nici un hardware sau calculator anumit si e simplu de scris programe care se pot executa fara nici o modificare pe diferite calculatoare care au limbajul C implementat. Aceasta carte are drept scop sa-l ajute pe cititor sa invete sa programeze in C. Ea contine o initiere, pentru ca noii utilizatori sa poata incepe cit mai repede posibil, capitole separate pentru fiecare caracteristica majora, si un manual de referinta. Marea parte a textului nu se bazeaza atit pe expunerea de reguli si propozitii cit pe citirea, scrierea si revizuirea de exemple. In cea mai mare parte exemplele sint programe reale si sint complete si nu fragmente izolate. Toate exemplele au fost testate direct
din text, care este intr-o forma citibila pe calculator. Pe linga faptul ca am aratat cum se utilizeaza efectiv limbajul, am incercat in plus, acolo unde era posibil, sa-l ilustram cu algoritmi utili si cu principii de bun stil in programare si proiectare sanatoasa. Aceasta carte nu este un manual introductiv de programare. Ea presupune anumite familiaritati cu conceptele. de baza din programare, ca variabile, instructiuni de asignare, bucle, functii. Cu toate acestea, un programator novice va fi in stare sa citeasca
cartea si sa-si insuseasca limbajul, chiar daca ajutorul unui coleg cu experienta mai mare i-ar usura munca foarte mult. In experienta noastra, C
s-a dovedit un limbaj placut, expresiv si adaptabil pentru o mare varietate de programe. Este usor de invatat si "se poarta bine" pe masura ce experienta in programare cu el creste. Speram ca aceasta carte va va ajuta sa-l folositi bine.
C este un limbaj de programare cu scop general ale carui caracteristici sint economia de expresie, structuri moderne de control al fluxului si de date, precum si un set bogat de operatori. C nu este un limbaj de nivel "foarte inalt", nici "mare", si nu este specializat vreunei arii particulare de aplicatii. Dar absenta in restrictii si generalitatea sa il fac mai convenabil si mai de efect pentru mai multe scopuri decit limbaje presupuse mai puternice. C a fost la inceput proiectat si implementat pe sistemul de operare UNIX pe DEC PDP11 de catre Dennis Ritchie. Sistemul de operare, compilatorul C si in mod esential, toate programele de aplicatii ale lui UNIX (inclusiv software-ul folosit pentru a pregati cartea aceasta) sint scrise in C. Compilatoare de C exista deasemenea si pe mai multe alte calculatoare, intre care IBM System/370 Honeywell 6000 si Interdata 8/32. C nu este legat de nici un hardware sau calculator anumit si e simplu de scris programe care se pot executa fara nici o modificare pe diferite calculatoare care au limbajul C implementat. Aceasta carte are drept scop sa-l ajute pe cititor sa invete sa programeze in C. Ea contine o initiere, pentru ca noii utilizatori sa poata incepe cit mai repede posibil, capitole separate pentru fiecare caracteristica majora, si un manual de referinta. Marea parte a textului nu se bazeaza atit pe expunerea de reguli si propozitii cit pe citirea, scrierea si revizuirea de exemple. In cea mai mare parte exemplele sint programe reale si sint complete si nu fragmente izolate. Toate exemplele au fost testate direct
din text, care este intr-o forma citibila pe calculator. Pe linga faptul ca am aratat cum se utilizeaza efectiv limbajul, am incercat in plus, acolo unde era posibil, sa-l ilustram cu algoritmi utili si cu principii de bun stil in programare si proiectare sanatoasa. Aceasta carte nu este un manual introductiv de programare. Ea presupune anumite familiaritati cu conceptele. de baza din programare, ca variabile, instructiuni de asignare, bucle, functii. Cu toate acestea, un programator novice va fi in stare sa citeasca
cartea si sa-si insuseasca limbajul, chiar daca ajutorul unui coleg cu experienta mai mare i-ar usura munca foarte mult. In experienta noastra, C
s-a dovedit un limbaj placut, expresiv si adaptabil pentru o mare varietate de programe. Este usor de invatat si "se poarta bine" pe masura ce experienta in programare cu el creste. Speram ca aceasta carte va va ajuta sa-l folositi bine.
Funny thing is, you don't even need to install SuSE to go through the dependencies mess you just described. FreeBSD's Linux emulation is excellent enough that it even includes a basic Redhat 6.2 install in/usr/ports/emulators/linux_base-62 (or Redhat 7 in/usr/ports/emulators/linux_base-7) - from there, you could install RPMs as you see fit and all the stuff will go into/compat/linux.
So really, if, for some inexplicable reason, you don't like ports and want to use RPMs with FreeBSD, you can do that:)
I must be
an idiot, because deCSS makes it sooo easy to pirate DVDs, and I can't even get the SOB to play them
By no means are you an idiot. DVD playing under Linux isn't quite there yet. I recently ranted about this elsewhere. Do a search for "linux DVD playing" on google, and you end up with the so-called "Linux DVD Playing Howto" which tells you to use livid/oms. Oms is dead. The "Linux DVD Playing Howto" is completely misleading, but you won't realize this until you've invested at least three or four hours getting the latest oms CVS and then figuring which decss plugin to use (as there are at least three but only one actually works). If you manage to finally get something that can read DVDs and output to your monitor, you'll find that oms doesn't do sound sync, so you still won't be able to watch movies.
So your next step is to complain on a forum like slashdot (this is what I did). You will then get replies telling you something to the order of "you are a fucking idiot, oms is dead, you should use xine/mplayer, it works better than in windows for me." So then you try xine or mplayer. But first, you must update your kernel, then update to XFree86 4.2, then update your SDL and maybe even update your gcc and binutils as mplayer won't even compile (well, actually it fails at the assembly step) with older versions of binutils. If you choose xine, you then have to figure out which decss plugin to use as there are quite a few to choose from, and only one or two that work (I understood dvdnav was the one to use, but an anonymous comrade just pointed out a different one in this thread). If you choose mplayer, you're in for a treat: here are the installation instructions. It took me about an hour and a half to go through those instructions before I was finally able to run mplayer's configure script. And if you think you can download some pre-built binary, you're wrong: all the mplayer asm optimizations are determed by your CPU type, which is determined by the configure script, not through run-time detection. Fortunately, mplayer does not require a separate decss plugin, so you don't have to go hunting through mailing lists and online forums to figure out which decss plugin works and which decss plugins are crap.
So, once you've compiled mplayer or xine and you've sufficiently frobbed your/proc to turn on DMA on your CD drive and get your MTRRs set up, you can actually run these programs and see if you get DVD output. Unfortunately, this is the point where you find out that the XFree86 4.2 ATI Rage 3D driver claims to support the XV extension, but, in fact, does not work correctly, causing xine and mplayer to fail on startup. So, now you have to use some "output plugin" that does not require the XV extension. The only output plugin capable enough to play DVDs would be the SDL output plugin, so you try to use that (you did remeber to enable SDL support at./configure, didn't you?).
My suggestion: forget it. Your time is expensive and you have better things to do. There is a very vocal minority of Linux users who claim that DVD playing under Linux works beautifully: I can't argue with them. Linux DVD playback works well for them, but not for the rest of us. Look at it this way: you can spend one or two days figuring out if DVD playback will even work with your hardware, or you could go to a temp agency and get some crap job for a weekend, make $150 and buy a dedicated DVD player to hook up to your TV. Now, cut out the crap temp job which was only meant to demonstrate the value of your time, go buy the damned player, and be absolutely 100% certain that you'll be watching DVDs by the end of the weekend.
These are some very interesting ideas: on the other hand, after some thought, I realized I wouldn't want a house and appliances like this.
This violates KISS: with the current setup, about the only thing that can go wrong is that I trip a breaker or blow a fuse. I can then go to my box and flip the breaker or go to the hardware store and get a new fuse. With a complex system like you imagine, almost any problem would require a professional electrician to fix and expensive components to replace. Also, batteries don't last forever, so you now have a recurring maintenance cost if your UPS system is "on-line" ("on-line" is what the UPS people call systems where the input AC feeds the battery and the battery feeds the output and "off-line" systems are where the AC passes through except when there's a problem, in which case there's some very fine circuitry which very quickly switches to the battery - obviously marketing jargon, an engineer would have come up with more descriptive terms).
This is sort of like what happened with automobiles: a friend of mine used to have this '67 VW Beetle. I flipped through the Chilton's for that car, and the great thing is that you could understand ALL of the car and fix most things yourself. I have a 1999 Pontiac Grand Am, and I can do very little work on this car since I don't have expensive diagnosis equipment.
Very interesting ideas, but I certainly don't want to be one of the first to have such an experimental house: I'll stick to simple breakers and fuses for now. However, if your ideas are implemented on a wide-spread basis, I'll jump in: as much as I like the idea of tinkering with a '67 Beetle, I enjoy driving my Grand Am much more.
s it possible to transfer electrical power from a source to a device without a wire?
Absolutely. When I was in college, my first-year physics professor had this interesting demonstration. He had a small light bulb stuck on the middle of a rod, and a radio. He would turn on the radio, stand at the other end of the auditorium and the bulb would light up if he held the rod horizontally, but it wouldn't light up if he held it vertically (the rod acted like a standard 1 dB antenna). I think his demonstration had something to do with polarization (not too big on physics), but the point is that it can be done.
Other people have probably already thought of it, so there's probably a reason it's not currently being used. One possible problem might be that in order to supply any decent amount of power, the watts you have to pump through the air will get dangerous. High-power radio waves can kill you: first, they'll make you sterile, then, after a while, you'll get a headache and a stomach ache. By the time you feel any pain, you're well on your way to death (at least this is what happens at the microwave end of the spectrum, I don't know what happens with higher frequency electromagnetic waves).
From what I've heard Stallman say during one of his speeches they had a lot of problems debugging it.
Yes, I've also been to one of his speeches (his speech was kind of boring - it basically rehashed all of the information available on the GNU/FSF websites and I was quite disappointed) and I heard the same story. I don't buy it. Apple managed to debug a multi-threaded multi-processor microkernel-based system. Granted, Apple has the resources to pay a small group of highly-skilled engineers to concentrate on a project, whereas the distributed development model common in most Free/OSS projects may not be well-suited for kernel work. OTOH, Linux employs a very open development model, and the FSF's own projects (like emacs and gcc) generally use very closed development models (eg, you have to be on a certain mailing list to get access to emacs betas - no public CVS). So you see, these arguments can't really explain HURD's problems, so that's why I'm confused.
Linux is pretty much based on "stuff that works"
I think this is closer to the real reason. I think HURD may have a bit of the "Ivory Tower" problem. I recently saw on a HURD mailing list a problem someone was having porting over some network program to HURD. HURD puts no limits on the size of strings returned by the gethost* functions, whereas every other Unix system has a well-specified limit on the length of domain names. This makes it difficult to pre-allocate a buffer for a hostname, which in turn, makes network programming in C more difficult (and I'll pre-emptively tell you HLL folks to bugger off because C is still the de-facto language for network programming).
The HURD folks came up with some riduculous artificial example of a hostname that breaks under BIND/glibc/Linux.
Whenever I'm writing some program, I have to make certain decisions. For instance, I have to decide what to abstract into a module and what to hard-code in. If you don't abstract anything, you'll end up with spaghetti code, but if you try to abstract everything, you'll end up nowhere. At one point, you have to sit down and tell yourself "now, you write the code that accomplishes your goal."
Anyway, I'll probably be sticking to Linux and FreeBSD for quite a while. I'd like it if DevFS were more accepted, if user-level filesystems became a standard part of Linux and if capabilities were made useful under Linux, but as it is right now, Linux and FreeBSD are actually usable operating systems, which is something I'm not sure I can say about HURD.
Mac OS X (and Darwin) is based on a Mach derivative
Not fucking true. Mac OSX is based on FreeBSD(or some other BSD). Hurd is GPL'd, therefore Apple
could not use it and keep OSX closed source.
It seems some people thought I was a troll and modded down my original post, while leaving your written diarrhea un-moderated, so I feel obliged to respond. Normally, I don't give you ACs a chance to say "YHBT", but I'll make an exception for Your Emminence.
OS X is indeed based on a mach microkernel. Not the GNU Mach microkernel, but a mach microkernel derivative (Mach was more-or-less a "proof-of-concept" of the microkernel idea written at CMU and GNU mach was written 'cause the MIT boys decided to have a pissing contest with the CMU boys). Have you ever used OS X? No? Well, then perhaps you'll see this when you do in fact use OS X for the first time:
Granted, 2.7 megabytes isn't very "micro" but a microkernel has nothing to do with the size of the kernel binary, and everything to do with the ways the kernel components communicate with each other.
OS X is a port of some of the FreeBSD userland into Apple's mach-based environment. I don't know if they used any of the FreeBSD kernel code, but most everything in the userland (that is, the userland I care about which is the Unix subsystem) is a straight port of the FreeBSD stuff. Even the manpages still have the FreeBSD emblems on them.
So, yes, it is in fact possible to write a successful microkernel-based system. NT is (or, at least, the NT kernel ideas were) microkernel-based, and Apple's OS X is microkernel based. If you think you can simply port over a FreeBSD driver to OS X, you're sorely mistaken.
Right, I realized this upon further thought after I posted. As for the fool who claimed that I was deliberately spreading FUD: fuck off. I was just trying to figure out what the hell's wrong with GNU Mach/HURD. There have to be some technical reasons (not just political reasons) why this project has been around so long and is only now available as an alpha distribution.
Still, I have to question GNU Mach - the newer versions are going to use OSKit. OSKit is basically a collection of various drivers for PCs. Now I've messed with OSKit superficially for my own little kernel project, and my impression was that OSKit was meant for two groups: (1) students in an OS class or hobbyists playing around with writing an OS (that would be me), and (2) researchers who want to do, for instance, work on VM or scheduling algorithms. Both groups who don't want to deal with the details of peculiar hardware. Anyway, my impression was that OSKit is meant more for experimentation, not a production-level Unix-like kernel. OSKit was very nice, don't get me wrong (nice APIs, you can plug in the drivers into your own kernel fairly easily, as opposed to Linux device drivers, which you have to rewrite from scratch if you want to use them outside of Linux) - but I just don't think it's the right thing for an honest-to-God production system.
Which is slashdotted. I read a different article which didn't mention the upcoming AGP version. Might be an interesting machine - still, I would use at least a 250W PSU for an XP1800+, as I'm somewhat paranoid about stability.
Being a microkernel does not mean that it should only support ancient hardware. If GNU Mach did not support reasonable sized disks until now, it means there is a problem with GNU Mach and not that this is a "feature" of a microkernel - most likely, the GNU Mach people got an abstraction wrong somewhere. Example: old versions of the HURD diskfs server would mmap the entire disk: this lead to a 1 GB partition size limit (see here).
Mac OS X (and Darwin) is based on a Mach derivative, and it has always supported large hard disks. It also supports booting off a network or a firewire- or USB-attached hard disk. If GNU's Mach microkernel can't do these things, it leads me to question the viability of GNU Mach (and I don't know if GNU Mach can do these things - it very well might, but I'm willing to bet karma that it can't).
The PSU outputs 200W - is this sufficient for the newer Athlons?
It comes with onboard video, but I would rather buy my own video card. Does it come with an AGP slot? AGP 1x, 2x? After looking at the pictures of the back of the case, I don't see where an AGP card would have video port - there are two obvious PCI slots on the back, but I don't see room for an AGP slot. Very few people still make high-performance PCI video cards
I'll second that. The single most useful tool I had in college (besides laptop). I still have mine and the knife on it is still extremely sharp. The can opener on it came in very useful in college, and the screwdriver is exactly the right size for the screws you'll find on PCs. It's also made out of steel, so the phillips screwdriver head didn't get stripped after lots of use.
Also, someone else already mentioned that lock picking tools might be illegal in her state. If you check the MIT Guide to Lock Picking, you'll see they mention that these are definitely illegal in MA, ME, NH and NY, so be careful. Also you might want to give her a piece of advice: fake IDs are illegal and have extremely stiff penalties. In addition, fake IDs aren't very useful in college, as even the most introverted, asocial geek can easily find some older colleague to buy the requisite vodka.
Am I the only one, or is anyone else reminded of old Front 242 and Front Line Assembly music videos when they see that thing? I mean, slap some Japanese characters onto that thing and it looks like it came straight out of FLA's mindphaser video or maybe KMFDM's Juke Joint Jezebel. Eerie.
I think part of the probem is that IBM is huge. The left hand doesn't know what the right is doing. The way I understand IBM's structure is that it's not one large, centrally-managed company, but rather a bunch of loosely grouped companies. The VP of mid-range servers might have a woody for Linux, but that doesn't mean the VP of thinkpads has to do anything with Linux.
What I'd like to know is exactly who in IBM is pushing Linux and what divisions they oversee. The whole s390 Linux thing took me completely by surprise as I had no idea the big iron IBM folks had any interest in Linux; from what I understand, this started as a bunch of s390 engineers messing about with a VM during their lunch hour, but now it seems like it's getting attention from above (which is very cool, but somewhat unexpected for those of us who've been in Corporate America for too long).
I can't imagine an ebullience of Linux enthusiasm overtaking all ranks of IBM, so I'm guessing there's someone higher-up who's pushing Linux. I'd like to know who these people are and what parts of IBM this affects and does not affect.
Anyway, it'd be better if someone on slashdot with inside info could answer this question. I don't want to bore these engineers with politics (I'm looking forward to a hardcore technical interview, not some fluff that I can find on cnet or salon).
Guessing a company's domain. Eg, I want to see if there are any recalls on my Pontiac Grand Am, so I type in pontiac.com. As you've noted, this usage of domain names is pointless - instead, I'll go to google and type in "pontiac grand am recalls."
Recalling a domain name. I go to a cyber café and want to check slashdot. I type in slashdot.org into the browser and I read slashdot.
Now, I agree that use (1) is dead. However, I don't want to have to remember 64.28.67.150 to read slashdot, nor do I want to be dependent on google to find slashdot. Think of the pontiac example, where I'm looking for a specific page: google rankings change, but domain names change less often. If google decides they don't like the American Communist Party, I may have a hard time finding their website without DNS, whereas google does not control the cpusa.org domain name.
There are also other, less obvious, uses for DNS. For example, I can type in ftp11.freebsd.org and see if that's faster than ftp6.freebsd.org, without having to search for the FreeBSD mirrors page. You can also publish spammer's IP addresses to DNS tables, like what RBL does. That means when I write my MTA, I don't need a full HTTP engine in it along with an XML/SGML/HTML/WHATEVERML parser, but I can just do a simple "gethostbyname()" and see if that returns an error. There are lots of other creative abuses for DNS.
Anyway, I think there's still a real need for DNS; however, DNS administration leads to so many politics...this article mentions a technical problem, but the real problems are social/political. These problems are much harder to solve.
What is commercially available software?? Do GPL products only available for free download count?
Spare me the sob story. If it were up to me, I'd keep this kid away from any general-purpose computer and have him complete his studies in juvie the old-fashioned way, with paper and pencil. Perhaps I would have allowed him to use a computer, but only if the computer had no modem, no NIC, no anything - I'll bet this kid never did anything off-line except play games.
We don't have the judge's actual ruling, only a snippit from a reporter, so we shouldn't even be discussing this - the judge may have given a very specific definition. If that definition excludes some possibly useful and harmless program, well then tant pis; the judge was generous enough allowing the kid anywhere near a computer as this kid has never used his computer for anything useful (Starcraft, IRC and launching DOS attacks are not useful nor educational).
I think the true definition of what a hacker is
was lost on the judge.
This "true definition" is completely rejected by mainstream America, and in fact, by most of the computing world, both in academia and the business world, both inside and outside of the US. The definition of hacker that you'll find in the New Hacker's Dictionary is an MIT-ism. Nobody outside of MIT ever uses it, and the FSF is so intimately intertwined with MIT that they don't realize this.
The old-school "hackers" that you're talking about never dwelled in the script kiddie community.
RMS was a math prodigy at Harvard; ESR was math and philosophy guy and never took a computer class; Larry Wall was trained as a linguist at Berkeley during the time when BSD was created, but he never touched Unix at Berkeley. And yet you would claim that barring this kid from using a specific set of software is going to stunt his growth?
So let's be honest: the warez hoarders and the script-kiddies on IRC - nothing useful has ever come out of these communities. All it has done is sully the reputation and the arguments of those who actually do any useful work: when Johannsen claims to a judge that he had a legitimate purpose for writing DeCSS, the judge won't believe him as he (and his peers) have already heard the same argument a thousand times from warez kiddies and the script kiddies trying to "show off" bad security.
My point here is that there is very little overlap between the kiddies and the "hackers" your talking about - all your insistence on propagating this MIT-ism of "hacker" does is confuse people as to which is which.
If you're going to resort to such tasteless and empty replies, please ensure that the same cannot be said of you. Your post makes so many grammatical and spelling errors that it's nearly illegible. In addition, your writing does not qualify you as any e. e. cummings, so please capitalize your sentences - it helps to distinguish between true sentences from those places where you insert the random period. Before displaying such extreme arrogance, at least ensure that your posts are passable as English prose. The parent poster took the time to explain an interesting point - please reciprocate.
If you are not a native English speaker: beware that "idiot" is a very strong word which is completely uncalled-for in this situation.
As for the content of your reply: you are correct in that the majority of the activities you do on the Internet cannot be queued, but only if you take this majority by the time you spend at your computer. The bandwidth problem is not caused by people surfing slashdot or reading email. The bandwidth problem is caused by the warez kiddies trading ISOs, people who buy the latest Maxtors to fill up with Kazaa-downloaded mp3s and rabid porn-surfers downloading mpegs. Email and "legitimate" web traffic count for very little when measured by bandwidth. These are two very different metrics (bandwidth and time) and the problem ISPs are facing is that they have a limited supply of bandwidth which gets used up by the Kazaa freaks/warez kiddies/porn surfers during peak times. These three categories of customers could certainly queue up their transfers to off-peak hours, leaving the lines free for email and "legitimate" web traffic; however, the parent poster very astutely points out that schemes like Comcast's leave no incentive to do this.
Maybe its a
bum, maybe its an infant with a near zero chance of survival, but you are making your way down a slippery
slope.
I find it interesting that you mention this explicitly. You may know that this is a logical fallacy; the only question that remains is whether you didn't know this, or whether you knew this and were trolling. I'm betting on the latter, judging from the title of your post and words like "it is only a matter of
time before you..." which are the mainstays of such arguments.
I hate to be the one who spoils your fun, but this is a very well-constructed and successful troll.
I am replying to this with my +2 bonus so you moderators will see this - this guy got a +3 for complete and utter crap:
placement of holes and such are used to implement h, the planck unit of action.
then ram them together to get a first order approximation of what they'll find during a (much more
expensive!) accelerator run..
OMFG - moderators actually take this pseudo-intellecualist crap seriously?! Look at this guy's history page - he does this all the time. I've responded before when he came up with some crap about gcc implementing "just-in-time assembly" - and he got a +4 informative for that. Do some people just mod up when they see big scary words?
If you're going to moderate this guy, I'd suggest +5 funny. It's amazing just how successful he is at spewing total crap and getting gullible moderators to believe him. An excellent troll (troll in the old usenet sense of the word, not the "BSD is dying"/goatse.cx slashdot kind troll), a true master of his trade. Those who know anything about any technical matters whatsoever are in on the joke, while those who are clueless just nod and smile.
if there's anybody in the
world who has a pretty good idea how much revenue Microsoft is losing because of Linux, it must be Gates,
Ballmer, and the rest of Microsoft's upper echelon.
And I think they're getting scared.
Microsoft is scared. But they're not scared that they're losing money to Linux.
In the section where I work, it's become common practice not to buy any software that does come with source. That includes database apps written specifically for what we do and marketted to a small niche, utility programs and development tools. The software doesn't have to be "Free" or Open Source - it can come with an NDA, but it must come with source code. Why, you ask? My management now understands the power of having source code. If there's a bug, we fix it. If we need a feature, we add it. We're less dependent on third parties to complete our jobs.
NB the ridicule against MS when they claimed that keeping their source code secret was a matter of security. The mainstream press (and perhaps mainstream America) is starting to understand what we techies mean by "security through obscurity." A few years ago, MS could get away with a move like this and most people wouldn't have given it much notice.
Look at the moves toward open standards, which MS is grudgingly accepting. Things like XML, documented networking protocols, standardized programming languages. People have always demanded interoperability, but they now understand that interoperability comes through open standards.
MS has $40 in the bank, and yet they're still making dumb moves against Linux - moves like that "national security" announcement a few days ago. These moves show that they're scared - they're making dumb moves which may hurt their image and their bottom line in the end, and in the business world, those dumb moves which hurt your bottom line are the dumbest dumb moves.
But what are they scared of? Are they afraid that $40 billion will become $39 billion? Would you risk attacking Linux/Free software/Open Source so vehemently at the threat of losing one fortieth of your company's stockpile?
Microsoft is not afraid of losing money to Linux. They're afraid of an idea. When people demand source code in order to reduce vendor lock-in, fix bugs and add features, when the public recognizes the crap which MS is claiming as security, when business starts demanding open standards - when these things happen, that's a problem for MS. The MS executives are not foolish - they realize a few hundred million dollars is not such a huge problem for them at the moment. However, what could be a huge problem for them is the death of their business model. That's what they're afraid of.
Re:This will probably come out "ignorant"...
on
Unlimited Airwaves
·
· Score: 3, Informative
To implement what you're talking about, you need some sort of time sync. Basically, what you're talking about is very similar to how ethernet works, but there are two fundamental differences between ethernet and radio at one specific frequency: with ethernet, you can both listen and broadcast at the same time (which means you can detect when you have a collision, thus CSMA/CD); with radio, you cannot listen while you're transmitting because your signal will drown out any incoming signal. This means you need some way of saying "OK, you can broadcast now." You could do this either on a time-slice basis (like 802.11) or with a token-passing scheme (and there are some wireless protocols that do token-passing). Another problem is that you might have three radios, like this:
A ---- B ---- C
where A is four dashes away from B and B is four dashes away from C. Suppose that a signal "lasts" for five dashes. That means A and C can't see each other, but B can see both. This brings up other nasty problems with simple protocols (and wireless protocols like 802.11 deal with this).
So, the simple packet-addressing scheme won't work for two-way communication. As for one-way communication, there's no need to "label" the recipient of a broadcast; radio is inherently broadcast, so everyone can hear everything anyway.
Which means that the OpenBSD acts as a repeater (a hub) without any IP addresses on the 2 NICs, and
without touching the packets it lets go through.
Have I correctly understood what you said OpenBSD can do?
Yes, this is exactly correct.
His goal is to send packets on NIC 1, through his switching equipment, then through NIC 2, and check for
errors.
You explained it more clearly than he did:)
This makes sense - it's much easier to write single a simple program that sends out data and then reads it back in, checking for errors, than it is to write two programs which run on separate machines to check the integrity.
My suggestion would then be to modify the kernel. I imagine it shouldn't be too hard to find the place in the kernel where it does this optimization and simply comment it out. Whenever I've needed to make a simple modification to the Linux kernel (like allowing people in group 80 to listen on port 80 to ensure my web server never starts as root, and simple stuff like that), I've found that the Linux kernel is pretty easy to grok and modify. In addition, this will show his management the power of having source code (one of his goals), as this sort of modification would probably be really hard to do with Windows:)
Slashdot Mirror
That is immensely cool. I've only been using it for five minutes, but I already can't live without it. You learn something every day.
history | grep 'command'
If you're using bash or zsh with the default emacs-like bindings, you can use ctrl-r to do an interactive backwards search in your history. Just keep hitting ctrl-r to search deeper back into the history.
Also, the one thing I've noted a lot of intermediate Linux users don't know about, but find very useful upon investigation is job control. Even with good window management and multiple xterms, job control is very useful: I often have three or four jobs on each xterm. Also, a neat trick: with zsh or bash, "fg %-" goes back to the second-to-last job. You can use this to quickly suspend and switch between two jobs continuously (eg, after you've done it once, "ctrl-z, ctrl-p, enter" switches to the "other" job).
Also, if there's a long command I recently executed, I usually won't search through history, but rather use the "!cmd" thing. Eg, if you've recently run "gcc -g -Wall -O3 -blahblah ..." a few commands ago, you can do it again by just typing "!gc" without searching. I guess it's really a question of preference, but I picked this up from the older gurus who were weaned on the monstrosity which is the C shell.
Here are some stupid shell tricks I've found moderately useful:
- bash: HISTCONTROL=ignoreboth, zsh: setopt HIST_IGNORE_SPACE;
This means when you type a command with a space in front of it, it doesn't go in your history. Useful if you do something that you don't want others to see (eg, xv ~/.pr0n/*.jpg).
- The zsh FAQ has an entry which describes how to get your xterm title to describe all sorts of fun stuff. Here's a bash equivalent:
- PATH management:
- This next one is absolutely necessary on any Linux machine:
- Recursively do something for each subdirectory:
Here's a dumb shell script that I call "randsort" - it prints out lines from stdin in a random order:This is useful 'cause you can do something like this:
xv `ls -t ~/.pr0n/*.jpg | head -200 | randsort`
and this randomization, for some reason, "feels" better than xv's -random option. It also has a number of "legitimate" uses. For instance:
Anyway, I got lots of stupid little crap like this. I try not to get too far into the customization stuff, as it's definitely a timesink and it's very important to be able to use a "standard" unix setup. For example, my .emacs is circa 80 KB (I'm big into Lisp), but I'm extremely proficient with vi, because there are lots of situations where emacs is not available, or vi is better-suited to the job.
The lameness filter is such a piece of horseshit. I mean, are the editors deliberately trying to prevent us from discussing code and technical matters? You'll need to re-indent all the snippets above because of this.
Lameness filter fodder:
C este un limbaj de programare cu scop general ale carui caracteristici sint economia de expresie, structuri moderne de control al fluxului si de date, precum si un set bogat de operatori. C nu este un limbaj de nivel "foarte inalt", nici "mare", si nu este specializat vreunei arii particulare de aplicatii. Dar absenta in restrictii si generalitatea sa il fac mai convenabil si mai de efect pentru mai multe scopuri decit limbaje presupuse mai puternice. C a fost la inceput proiectat si implementat pe sistemul de operare UNIX pe DEC PDP11 de catre Dennis Ritchie. Sistemul de operare, compilatorul C si in mod esential, toate programele de aplicatii ale lui UNIX (inclusiv software-ul folosit pentru a pregati cartea aceasta) sint scrise in C. Compilatoare de C exista deasemenea si pe mai multe alte calculatoare, intre care IBM System/370 Honeywell 6000 si Interdata 8/32. C nu este legat de nici un hardware sau calculator anumit si e simplu de scris programe care se pot executa fara nici o modificare pe diferite calculatoare care au limbajul C implementat. Aceasta carte are drept scop sa-l ajute pe cititor sa invete sa programeze in C. Ea contine o initiere, pentru ca noii utilizatori sa poata incepe cit mai repede posibil, capitole separate pentru fiecare caracteristica majora, si un manual de referinta. Marea parte a textului nu se bazeaza atit pe expunerea de reguli si propozitii cit pe citirea, scrierea si revizuirea de exemple. In cea mai mare parte exemplele sint programe reale si sint complete si nu fragmente izolate. Toate exemplele au fost testate direct din text, care este intr-o forma citibila pe calculator. Pe linga faptul ca am aratat cum se utilizeaza efectiv limbajul, am incercat in plus, acolo unde era posibil, sa-l ilustram cu algoritmi utili si cu principii de bun stil in programare si proiectare sanatoasa. Aceasta carte nu este un manual introductiv de programare. Ea presupune anumite familiaritati cu conceptele. de baza din programare, ca variabile, instructiuni de asignare, bucle, functii. Cu toate acestea, un programator novice va fi in stare sa citeasca cartea si sa-si insuseasca limbajul, chiar daca ajutorul unui coleg cu experienta mai mare i-ar usura munca foarte mult. In experienta noastra, C s-a dovedit un limbaj placut, expresiv si adaptabil pentru o mare varietate de programe. Este usor de invatat si "se poarta bine" pe masura ce experienta in programare cu el creste. Speram ca aceasta carte va va ajuta sa-l folositi bine.
C este un limbaj de programare cu scop general ale carui caracteristici sint economia de expresie, structuri moderne de control al fluxului si de date, precum si un set bogat de operatori. C nu este un limbaj de nivel "foarte inalt", nici "mare", si nu este specializat vreunei arii particulare de aplicatii. Dar absenta in restrictii si generalitatea sa il fac mai convenabil si mai de efect pentru mai multe scopuri decit limbaje presupuse mai puternice. C a fost la inceput proiectat si implementat pe sistemul de operare UNIX pe DEC PDP11 de catre Dennis Ritchie. Sistemul de operare, compilatorul C si in mod esential, toate programele de aplicatii ale lui UNIX (inclusiv software-ul folosit pentru a pregati cartea aceasta) sint scrise in C. Compilatoare de C exista deasemenea si pe mai multe alte calculatoare, intre care IBM System/370 Honeywell 6000 si Interdata 8/32. C nu este legat de nici un hardware sau calculator anumit si e simplu de scris programe care se pot executa fara nici o modificare pe diferite calculatoare care au limbajul C implementat. Aceasta carte are drept scop sa-l ajute pe cititor sa invete sa programeze in C. Ea contine o initiere, pentru ca noii utilizatori sa poata incepe cit mai repede posibil, capitole separate pentru fiecare caracteristica majora, si un manual de referinta. Marea parte a textului nu se bazeaza atit pe expunerea de reguli si propozitii cit pe citirea, scrierea si revizuirea de exemple. In cea mai mare parte exemplele sint programe reale si sint complete si nu fragmente izolate. Toate exemplele au fost testate direct din text, care este intr-o forma citibila pe calculator. Pe linga faptul ca am aratat cum se utilizeaza efectiv limbajul, am incercat in plus, acolo unde era posibil, sa-l ilustram cu algoritmi utili si cu principii de bun stil in programare si proiectare sanatoasa. Aceasta carte nu este un manual introductiv de programare. Ea presupune anumite familiaritati cu conceptele. de baza din programare, ca variabile, instructiuni de asignare, bucle, functii. Cu toate acestea, un programator novice va fi in stare sa citeasca cartea si sa-si insuseasca limbajul, chiar daca ajutorul unui coleg cu experienta mai mare i-ar usura munca foarte mult. In experienta noastra, C s-a dovedit un limbaj placut, expresiv si adaptabil pentru o mare varietate de programe. Este usor de invatat si "se poarta bine" pe masura ce experienta in programare cu el creste. Speram ca aceasta carte va va ajuta sa-l folositi bine.
So really, if, for some inexplicable reason, you don't like ports and want to use RPMs with FreeBSD, you can do that :)
By no means are you an idiot. DVD playing under Linux isn't quite there yet. I recently ranted about this elsewhere. Do a search for "linux DVD playing" on google, and you end up with the so-called "Linux DVD Playing Howto" which tells you to use livid/oms. Oms is dead. The "Linux DVD Playing Howto" is completely misleading, but you won't realize this until you've invested at least three or four hours getting the latest oms CVS and then figuring which decss plugin to use (as there are at least three but only one actually works). If you manage to finally get something that can read DVDs and output to your monitor, you'll find that oms doesn't do sound sync, so you still won't be able to watch movies.
So your next step is to complain on a forum like slashdot (this is what I did). You will then get replies telling you something to the order of "you are a fucking idiot, oms is dead, you should use xine/mplayer, it works better than in windows for me." So then you try xine or mplayer. But first, you must update your kernel, then update to XFree86 4.2, then update your SDL and maybe even update your gcc and binutils as mplayer won't even compile (well, actually it fails at the assembly step) with older versions of binutils. If you choose xine, you then have to figure out which decss plugin to use as there are quite a few to choose from, and only one or two that work (I understood dvdnav was the one to use, but an anonymous comrade just pointed out a different one in this thread). If you choose mplayer, you're in for a treat: here are the installation instructions. It took me about an hour and a half to go through those instructions before I was finally able to run mplayer's configure script. And if you think you can download some pre-built binary, you're wrong: all the mplayer asm optimizations are determed by your CPU type, which is determined by the configure script, not through run-time detection. Fortunately, mplayer does not require a separate decss plugin, so you don't have to go hunting through mailing lists and online forums to figure out which decss plugin works and which decss plugins are crap.
So, once you've compiled mplayer or xine and you've sufficiently frobbed your /proc to turn on DMA on your CD drive and get your MTRRs set up, you can actually run these programs and see if you get DVD output. Unfortunately, this is the point where you find out that the XFree86 4.2 ATI Rage 3D driver claims to support the XV extension, but, in fact, does not work correctly, causing xine and mplayer to fail on startup. So, now you have to use some "output plugin" that does not require the XV extension. The only output plugin capable enough to play DVDs would be the SDL output plugin, so you try to use that (you did remeber to enable SDL support at ./configure, didn't you?).
My suggestion: forget it. Your time is expensive and you have better things to do. There is a very vocal minority of Linux users who claim that DVD playing under Linux works beautifully: I can't argue with them. Linux DVD playback works well for them, but not for the rest of us. Look at it this way: you can spend one or two days figuring out if DVD playback will even work with your hardware, or you could go to a temp agency and get some crap job for a weekend, make $150 and buy a dedicated DVD player to hook up to your TV. Now, cut out the crap temp job which was only meant to demonstrate the value of your time, go buy the damned player, and be absolutely 100% certain that you'll be watching DVDs by the end of the weekend.
This violates KISS: with the current setup, about the only thing that can go wrong is that I trip a breaker or blow a fuse. I can then go to my box and flip the breaker or go to the hardware store and get a new fuse. With a complex system like you imagine, almost any problem would require a professional electrician to fix and expensive components to replace. Also, batteries don't last forever, so you now have a recurring maintenance cost if your UPS system is "on-line" ("on-line" is what the UPS people call systems where the input AC feeds the battery and the battery feeds the output and "off-line" systems are where the AC passes through except when there's a problem, in which case there's some very fine circuitry which very quickly switches to the battery - obviously marketing jargon, an engineer would have come up with more descriptive terms).
This is sort of like what happened with automobiles: a friend of mine used to have this '67 VW Beetle. I flipped through the Chilton's for that car, and the great thing is that you could understand ALL of the car and fix most things yourself. I have a 1999 Pontiac Grand Am, and I can do very little work on this car since I don't have expensive diagnosis equipment.
Very interesting ideas, but I certainly don't want to be one of the first to have such an experimental house: I'll stick to simple breakers and fuses for now. However, if your ideas are implemented on a wide-spread basis, I'll jump in: as much as I like the idea of tinkering with a '67 Beetle, I enjoy driving my Grand Am much more.
Absolutely. When I was in college, my first-year physics professor had this interesting demonstration. He had a small light bulb stuck on the middle of a rod, and a radio. He would turn on the radio, stand at the other end of the auditorium and the bulb would light up if he held the rod horizontally, but it wouldn't light up if he held it vertically (the rod acted like a standard 1 dB antenna). I think his demonstration had something to do with polarization (not too big on physics), but the point is that it can be done.
Other people have probably already thought of it, so there's probably a reason it's not currently being used. One possible problem might be that in order to supply any decent amount of power, the watts you have to pump through the air will get dangerous. High-power radio waves can kill you: first, they'll make you sterile, then, after a while, you'll get a headache and a stomach ache. By the time you feel any pain, you're well on your way to death (at least this is what happens at the microwave end of the spectrum, I don't know what happens with higher frequency electromagnetic waves).
Yes, I've also been to one of his speeches (his speech was kind of boring - it basically rehashed all of the information available on the GNU/FSF websites and I was quite disappointed) and I heard the same story. I don't buy it. Apple managed to debug a multi-threaded multi-processor microkernel-based system. Granted, Apple has the resources to pay a small group of highly-skilled engineers to concentrate on a project, whereas the distributed development model common in most Free/OSS projects may not be well-suited for kernel work. OTOH, Linux employs a very open development model, and the FSF's own projects (like emacs and gcc) generally use very closed development models (eg, you have to be on a certain mailing list to get access to emacs betas - no public CVS). So you see, these arguments can't really explain HURD's problems, so that's why I'm confused.
Linux is pretty much based on "stuff that works"
I think this is closer to the real reason. I think HURD may have a bit of the "Ivory Tower" problem. I recently saw on a HURD mailing list a problem someone was having porting over some network program to HURD. HURD puts no limits on the size of strings returned by the gethost* functions, whereas every other Unix system has a well-specified limit on the length of domain names. This makes it difficult to pre-allocate a buffer for a hostname, which in turn, makes network programming in C more difficult (and I'll pre-emptively tell you HLL folks to bugger off because C is still the de-facto language for network programming). The HURD folks came up with some riduculous artificial example of a hostname that breaks under BIND/glibc/Linux.
Whenever I'm writing some program, I have to make certain decisions. For instance, I have to decide what to abstract into a module and what to hard-code in. If you don't abstract anything, you'll end up with spaghetti code, but if you try to abstract everything, you'll end up nowhere. At one point, you have to sit down and tell yourself "now, you write the code that accomplishes your goal."
Anyway, I'll probably be sticking to Linux and FreeBSD for quite a while. I'd like it if DevFS were more accepted, if user-level filesystems became a standard part of Linux and if capabilities were made useful under Linux, but as it is right now, Linux and FreeBSD are actually usable operating systems, which is something I'm not sure I can say about HURD.
It seems some people thought I was a troll and modded down my original post, while leaving your written diarrhea un-moderated, so I feel obliged to respond. Normally, I don't give you ACs a chance to say "YHBT", but I'll make an exception for Your Emminence.
OS X is indeed based on a mach microkernel. Not the GNU Mach microkernel, but a mach microkernel derivative (Mach was more-or-less a "proof-of-concept" of the microkernel idea written at CMU and GNU mach was written 'cause the MIT boys decided to have a pissing contest with the CMU boys). Have you ever used OS X? No? Well, then perhaps you'll see this when you do in fact use OS X for the first time:
Granted, 2.7 megabytes isn't very "micro" but a microkernel has nothing to do with the size of the kernel binary, and everything to do with the ways the kernel components communicate with each other.
OS X is a port of some of the FreeBSD userland into Apple's mach-based environment. I don't know if they used any of the FreeBSD kernel code, but most everything in the userland (that is, the userland I care about which is the Unix subsystem) is a straight port of the FreeBSD stuff. Even the manpages still have the FreeBSD emblems on them.
So, yes, it is in fact possible to write a successful microkernel-based system. NT is (or, at least, the NT kernel ideas were) microkernel-based, and Apple's OS X is microkernel based. If you think you can simply port over a FreeBSD driver to OS X, you're sorely mistaken.
Right, I realized this upon further thought after I posted. As for the fool who claimed that I was deliberately spreading FUD: fuck off. I was just trying to figure out what the hell's wrong with GNU Mach/HURD. There have to be some technical reasons (not just political reasons) why this project has been around so long and is only now available as an alpha distribution.
Still, I have to question GNU Mach - the newer versions are going to use OSKit. OSKit is basically a collection of various drivers for PCs. Now I've messed with OSKit superficially for my own little kernel project, and my impression was that OSKit was meant for two groups: (1) students in an OS class or hobbyists playing around with writing an OS (that would be me), and (2) researchers who want to do, for instance, work on VM or scheduling algorithms. Both groups who don't want to deal with the details of peculiar hardware. Anyway, my impression was that OSKit is meant more for experimentation, not a production-level Unix-like kernel. OSKit was very nice, don't get me wrong (nice APIs, you can plug in the drivers into your own kernel fairly easily, as opposed to Linux device drivers, which you have to rewrite from scratch if you want to use them outside of Linux) - but I just don't think it's the right thing for an honest-to-God production system.
Which is slashdotted. I read a different article which didn't mention the upcoming AGP version. Might be an interesting machine - still, I would use at least a 250W PSU for an XP1800+, as I'm somewhat paranoid about stability.
Mac OS X (and Darwin) is based on a Mach derivative, and it has always supported large hard disks. It also supports booting off a network or a firewire- or USB-attached hard disk. If GNU's Mach microkernel can't do these things, it leads me to question the viability of GNU Mach (and I don't know if GNU Mach can do these things - it very well might, but I'm willing to bet karma that it can't).
I'll second that. The single most useful tool I had in college (besides laptop). I still have mine and the knife on it is still extremely sharp. The can opener on it came in very useful in college, and the screwdriver is exactly the right size for the screws you'll find on PCs. It's also made out of steel, so the phillips screwdriver head didn't get stripped after lots of use.
Also, someone else already mentioned that lock picking tools might be illegal in her state. If you check the MIT Guide to Lock Picking, you'll see they mention that these are definitely illegal in MA, ME, NH and NY, so be careful. Also you might want to give her a piece of advice: fake IDs are illegal and have extremely stiff penalties. In addition, fake IDs aren't very useful in college, as even the most introverted, asocial geek can easily find some older colleague to buy the requisite vodka.
Am I the only one, or is anyone else reminded of old Front 242 and Front Line Assembly music videos when they see that thing? I mean, slap some Japanese characters onto that thing and it looks like it came straight out of FLA's mindphaser video or maybe KMFDM's Juke Joint Jezebel. Eerie.
What I'd like to know is exactly who in IBM is pushing Linux and what divisions they oversee. The whole s390 Linux thing took me completely by surprise as I had no idea the big iron IBM folks had any interest in Linux; from what I understand, this started as a bunch of s390 engineers messing about with a VM during their lunch hour, but now it seems like it's getting attention from above (which is very cool, but somewhat unexpected for those of us who've been in Corporate America for too long).
I can't imagine an ebullience of Linux enthusiasm overtaking all ranks of IBM, so I'm guessing there's someone higher-up who's pushing Linux. I'd like to know who these people are and what parts of IBM this affects and does not affect.
Anyway, it'd be better if someone on slashdot with inside info could answer this question. I don't want to bore these engineers with politics (I'm looking forward to a hardcore technical interview, not some fluff that I can find on cnet or salon).
Absolutely. click here for a demonstration. I haven't yet used a browser that could handle the links on that page. I share your disgust.
Now, I agree that use (1) is dead. However, I don't want to have to remember 64.28.67.150 to read slashdot, nor do I want to be dependent on google to find slashdot. Think of the pontiac example, where I'm looking for a specific page: google rankings change, but domain names change less often. If google decides they don't like the American Communist Party, I may have a hard time finding their website without DNS, whereas google does not control the cpusa.org domain name.
There are also other, less obvious, uses for DNS. For example, I can type in ftp11.freebsd.org and see if that's faster than ftp6.freebsd.org, without having to search for the FreeBSD mirrors page. You can also publish spammer's IP addresses to DNS tables, like what RBL does. That means when I write my MTA, I don't need a full HTTP engine in it along with an XML/SGML/HTML/WHATEVERML parser, but I can just do a simple "gethostbyname()" and see if that returns an error. There are lots of other creative abuses for DNS.
Anyway, I think there's still a real need for DNS; however, DNS administration leads to so many politics...this article mentions a technical problem, but the real problems are social/political. These problems are much harder to solve.
Spare me the sob story. If it were up to me, I'd keep this kid away from any general-purpose computer and have him complete his studies in juvie the old-fashioned way, with paper and pencil. Perhaps I would have allowed him to use a computer, but only if the computer had no modem, no NIC, no anything - I'll bet this kid never did anything off-line except play games.
We don't have the judge's actual ruling, only a snippit from a reporter, so we shouldn't even be discussing this - the judge may have given a very specific definition. If that definition excludes some possibly useful and harmless program, well then tant pis; the judge was generous enough allowing the kid anywhere near a computer as this kid has never used his computer for anything useful (Starcraft, IRC and launching DOS attacks are not useful nor educational).
I think the true definition of what a hacker is was lost on the judge.
This "true definition" is completely rejected by mainstream America, and in fact, by most of the computing world, both in academia and the business world, both inside and outside of the US. The definition of hacker that you'll find in the New Hacker's Dictionary is an MIT-ism. Nobody outside of MIT ever uses it, and the FSF is so intimately intertwined with MIT that they don't realize this.
The old-school "hackers" that you're talking about never dwelled in the script kiddie community. RMS was a math prodigy at Harvard; ESR was math and philosophy guy and never took a computer class; Larry Wall was trained as a linguist at Berkeley during the time when BSD was created, but he never touched Unix at Berkeley. And yet you would claim that barring this kid from using a specific set of software is going to stunt his growth?
So let's be honest: the warez hoarders and the script-kiddies on IRC - nothing useful has ever come out of these communities. All it has done is sully the reputation and the arguments of those who actually do any useful work: when Johannsen claims to a judge that he had a legitimate purpose for writing DeCSS, the judge won't believe him as he (and his peers) have already heard the same argument a thousand times from warez kiddies and the script kiddies trying to "show off" bad security.
My point here is that there is very little overlap between the kiddies and the "hackers" your talking about - all your insistence on propagating this MIT-ism of "hacker" does is confuse people as to which is which.
If you are a native English speaker:
If you're going to resort to such tasteless and empty replies, please ensure that the same cannot be said of you. Your post makes so many grammatical and spelling errors that it's nearly illegible. In addition, your writing does not qualify you as any e. e. cummings, so please capitalize your sentences - it helps to distinguish between true sentences from those places where you insert the random period. Before displaying such extreme arrogance, at least ensure that your posts are passable as English prose. The parent poster took the time to explain an interesting point - please reciprocate.
If you are not a native English speaker: beware that "idiot" is a very strong word which is completely uncalled-for in this situation.
As for the content of your reply: you are correct in that the majority of the activities you do on the Internet cannot be queued, but only if you take this majority by the time you spend at your computer. The bandwidth problem is not caused by people surfing slashdot or reading email. The bandwidth problem is caused by the warez kiddies trading ISOs, people who buy the latest Maxtors to fill up with Kazaa-downloaded mp3s and rabid porn-surfers downloading mpegs. Email and "legitimate" web traffic count for very little when measured by bandwidth. These are two very different metrics (bandwidth and time) and the problem ISPs are facing is that they have a limited supply of bandwidth which gets used up by the Kazaa freaks/warez kiddies/porn surfers during peak times. These three categories of customers could certainly queue up their transfers to off-peak hours, leaving the lines free for email and "legitimate" web traffic; however, the parent poster very astutely points out that schemes like Comcast's leave no incentive to do this.
I find it interesting that you mention this explicitly. You may know that this is a logical fallacy; the only question that remains is whether you didn't know this, or whether you knew this and were trolling. I'm betting on the latter, judging from the title of your post and words like "it is only a matter of time before you..." which are the mainstays of such arguments.
I hate to be the one who spoils your fun, but this is a very well-constructed and successful troll.
placement of holes and such are used to implement h, the planck unit of action.
then ram them together to get a first order approximation of what they'll find during a (much more expensive!) accelerator run..
OMFG - moderators actually take this pseudo-intellecualist crap seriously?! Look at this guy's history page - he does this all the time. I've responded before when he came up with some crap about gcc implementing "just-in-time assembly" - and he got a +4 informative for that. Do some people just mod up when they see big scary words?
If you're going to moderate this guy, I'd suggest +5 funny. It's amazing just how successful he is at spewing total crap and getting gullible moderators to believe him. An excellent troll (troll in the old usenet sense of the word, not the "BSD is dying"/goatse.cx slashdot kind troll), a true master of his trade. Those who know anything about any technical matters whatsoever are in on the joke, while those who are clueless just nod and smile.
Ah, yes - news for nerds. Refreshing.
And I think they're getting scared.
Microsoft is scared. But they're not scared that they're losing money to Linux.
In the section where I work, it's become common practice not to buy any software that does come with source. That includes database apps written specifically for what we do and marketted to a small niche, utility programs and development tools. The software doesn't have to be "Free" or Open Source - it can come with an NDA, but it must come with source code. Why, you ask? My management now understands the power of having source code. If there's a bug, we fix it. If we need a feature, we add it. We're less dependent on third parties to complete our jobs.
NB the ridicule against MS when they claimed that keeping their source code secret was a matter of security. The mainstream press (and perhaps mainstream America) is starting to understand what we techies mean by "security through obscurity." A few years ago, MS could get away with a move like this and most people wouldn't have given it much notice.
Look at the moves toward open standards, which MS is grudgingly accepting. Things like XML, documented networking protocols, standardized programming languages. People have always demanded interoperability, but they now understand that interoperability comes through open standards.
MS has $40 in the bank, and yet they're still making dumb moves against Linux - moves like that "national security" announcement a few days ago. These moves show that they're scared - they're making dumb moves which may hurt their image and their bottom line in the end, and in the business world, those dumb moves which hurt your bottom line are the dumbest dumb moves. But what are they scared of? Are they afraid that $40 billion will become $39 billion? Would you risk attacking Linux/Free software/Open Source so vehemently at the threat of losing one fortieth of your company's stockpile?
Microsoft is not afraid of losing money to Linux. They're afraid of an idea. When people demand source code in order to reduce vendor lock-in, fix bugs and add features, when the public recognizes the crap which MS is claiming as security, when business starts demanding open standards - when these things happen, that's a problem for MS. The MS executives are not foolish - they realize a few hundred million dollars is not such a huge problem for them at the moment. However, what could be a huge problem for them is the death of their business model. That's what they're afraid of.
So, the simple packet-addressing scheme won't work for two-way communication. As for one-way communication, there's no need to "label" the recipient of a broadcast; radio is inherently broadcast, so everyone can hear everything anyway.
Yes, this is exactly correct.
His goal is to send packets on NIC 1, through his switching equipment, then through NIC 2, and check for errors.
You explained it more clearly than he did :)
This makes sense - it's much easier to write single a simple program that sends out data and then reads it back in, checking for errors, than it is to write two programs which run on separate machines to check the integrity.
My suggestion would then be to modify the kernel. I imagine it shouldn't be too hard to find the place in the kernel where it does this optimization and simply comment it out. Whenever I've needed to make a simple modification to the Linux kernel (like allowing people in group 80 to listen on port 80 to ensure my web server never starts as root, and simple stuff like that), I've found that the Linux kernel is pretty easy to grok and modify. In addition, this will show his management the power of having source code (one of his goals), as this sort of modification would probably be really hard to do with Windows :)