I didn't say that they shouldn't be bought. I said that they are overpriced. I think houses and cars are overpriced too, but I'm not advocating that we live in tents and walk thirty miles to work. I am definitely not saying that we should all go out and purchase cheaper IBMs.
We have a finite but nondeterministic number of Ultras here at work; four at the moment. I am well pleased with them. Occasionally there's an SGI machine, which is also nice but has a wacked-out library layout. But that's a different rant.
It's debatable. We have some of the vew SPARC V9 chips here where I admin, and they are verra verra nice. Also verra verra pricey.
Sun's biggest problem (and has been for some time) is that their hardware is way the hell overpriced, and their industry-standard stuff lags behind (e.g., their latest CDROM drives are a third the speed of a generic Plextor drive, but cost five times as much). Their custom hardware (UltraSPARC processors, say) is nice, but equally pricey.
There are some very handy things that you can do under Solaris/SPARC but not Solaris/x86. Even so, running on Intel whytanium will be a boost to Sun.
I would point out that running a spellchecker on the Taco Bell sign would have done/absolutely no good/.
I absolutely can't stand people who make mistakes like that (like the university newsletter reminding everyone that fire alarms are announced over "the pubic address system") and then complaining that "waaaah, but the spellchecker didn't catch it, it's not my fault." Yo, dumbass, "pubic" is spelled perfectly correctly.
Try using your $@!#?*@ brain instead of blindly clicking at a computer. The results can be amazing.
Oh, I didn't mean to imply that UNP is only an intro book. I bought the Second Edition because the First Edition and the APUE were so unbelievably useful.
I don't recall his website off the top of my head, but I think that uunet has a copy.
The latest (2nd) edition of _Unix Network Programming_ discusses IPv6. It's a really good introduction for somebody (like me) who knew jack-all about it to start with.
It's just technical enough that I can follow discussions about IPv6 implementation and management, but doesn't get into the really nasty details -- there are supposed to be other books for that, and _UNP_ has other topics to get to.
For the uninitiated, _Unix Network Programming, 2nd Edition_ is two or three volumes, all worth it, and written by the late W. Richard Stevens, Network God. RIP.
I think the games and "serious tools" have finally come full circle.
A much older gcc used to spawn nethack when it saw a programming construct that the authors didn't like. Now Doom spawns kill(1)/signal(2) when its users see a drooling, belching, fire-breathing construct that *they* don't like...
As a sysop for the Air Force Research Labs, I tell you straight up that I had nothing to do with it whatsoever. The fact that I now own massive shares of Sydney Opera House is a coincidence. Pay no attention to the man behind the curtain.
phil (hoping that nobody else in his directorate reads/.)
Several hard- and pseudo-hard-SF authors (e.g., Niven in several short stories, and Sterling in his recent _Distraction_ novel) have written stories involving an alternative application to the "listening to everything" scenario: devices which listen for the patterned sounds of a mugging, a rape, or gunfire. Then the police are called, or (assuming visual pattern recognition) the people involved are knocked out.
I for one want a small device to listen for the sounds of coworkers down the hall muttering, "Hmmm, maybe phil knows about this," and report it to me, so I can hide.
Has anybody ever seen a vendor offer transparent cases? Lots of folks make their own, but I've never heard of one off-the-shelf like that.
Dunno if I'd paint over it... having what appears to be a random collection of electronics under your arm or sitting on your desk can occasionally look neat. (I want internal parts that look like they're steam-powered, dammit.:-)
I'm not certain about the "six lines" exactly, but Feynman was the person who discovered exactly why the O-rings on the Shuttle (STS) solid rocket boosters (SRBs) weren't doing their thing during the Challenger explosion.
I remember the first time I read some of the prefaces leading up to the Jargon File; the ones dealing with "hacker writing style" in particular. I recall being surprised/amused when I discovered that many of them were traits I had already acquired -- and then came upon ESR's comment that "we may see a revival of letter writing as an art form" (quoting from memory).
We'll have to carefully distinguish between words that have assigned power (legal documents) and words that have intrinsic power (religious texts, letters). What do you want to bet that there won't be any difference from the law's viewpoint? (Er, I guess. I'm rambling now.)
The letter is absolutely excellent reading, but I'm wondering about the first sentence of the sixth paragraph:
"If the police ask you keep the demand to hand over the key secret, telling anyone would render you liable to 5 years in jail."
Perhaps somebody on the other side of the Pond could clear something up for this rebellious colonist.:-) What's to keep/every/ such key request from being "secret"? Is there provision in the bill such that certain extra circumstances must prevail in order for the demand itself to not be publicized?
That's a really good way of thinking about it. This begs the question: what happens to the environment (the project) when the number of inhabitants (the coders) outgrow it?
Obviously, a bunch of coders will leave to start work on a new/different project. But if they stay around instead of leaving, an amazing amount of damage would occur to whatever's being hacked on.
I can't think of any opensource projects off the top of my head that have been stripped down to tree bark and dust because there were too many coders. Anybody else?
(Halfway through rereading the Dune novels, so the whole ecology-as-culture thing is really stuck in my head right now.:-)
Granted it's been years since I played with Linux, but when building a kernel we had to "make config," or something similar, which would ask the user what to include in the kernel (while remembering choices from last time, etc, etc).
I'm assuming that today's distributions still do that, in some form or another. Why not just disable support for just about everything? It's what I used to do when building customized rescue diskettes. The resulting kernel got pretty small.
(Disclaimer: I don't know jack about embedded systems, and I don't know whether this process would bring the size down/enough/ to be useful. But you used to be able to rip a significant amount of stuff out of the kernel.)
> As a point of caution to those about to grab > this latest scanner and joyride, every military > installation & network is monitored 24/7. I > assure you, portscans are detected and the > source IP recorded & blocked. (To be specific, > for 15 days after the attack/intrusion; if it > occurs again, further measures are taken.)
Damn straight. I think our base blocks them for longer than 15 days, though... that may just be local extra paranoia. Not my baliwick, so I could be wrong.
> But then, it's a research institution, and > scientists don't like to sully their hands > with such mundane matters.:)
When I worked on base before, I used to try and make things convenient for my users as long as security never got compromised. If they came and complained, well, sorry, but that's the way things have to be. Usually they understood.
Lately I've decided that I won't even listen to "inconvenience" complaints. Screw 'em. My boxes haven't been cracked yet, and I'm not going to take any chances. So they have to go through extra steps. Waaah.
Re:Glacial compile times and huge dwarf builds
on
GCC 2.95 Released
·
· Score: 1
+ Ok, what exactly does that do to the + compile/test/debug cycle. [...] that's where + the ~8min's+ per compile becomes penal.
Do you want the 8 minutes, or the 130 MB?
I was defending the binary size, not the compile times.:-) Yeah, the lack of preprocessed headers can really hurt once they stop changing, but like I said, I (and others) have been surprised at the difference some extra coding makes. Things like redundant include guards really do honestly work on a large project, and testing-in-isolation helps you to run that debug cycle much quicker, with tiny little testcases.
It also helps to set TMPDIR to a ramdisk.
+ Has anybody thought about a gcc based build + environment that can be distributed
I'm not an expert (yet, dammit:-), but I have to wonder whether distributing a compiler would be worth the overhead. Distributing the entire build, though, where each machine works on a different source file, is very cool, and is just the next logical step in "seperate compilation." Dunno about splitting the individual compilations of files... I wonder if/how Plan 9 does this.
Re:Glacial compile times and huge dwarf builds
on
GCC 2.95 Released
·
· Score: 1
+ This is probably because of the lack of + precompiled headers. Much of the source + includes the headers to libs and system stuff.
Most probably. Without optimization, by far the bulk of a compiler's time is spent parsing.
Without meaning to sound condescending, I must at this point mention things like the redundant include guards described in the Lakos text. I found that the little extra typing really can speed up the compliation stage significantly.
+ 4 Meg executable swells to a mindboggling + 130MB of god-knows-what nonsense when the + -g flag is on.
Speaking only for myself, not the EGCS people: why do you care? It's the debugging version, not the production version.
I realize that's harsh, but for the most part my binary sizes don't get much attention from me until after I turn off -g, enable a string of space-saving optimizations, and then strip the binary.
+ the current situation sucks for those of us + with beefy apps.
My last major project was beefy enough, and egcs pulled through with flying colors for me. If you have suggestions, I'm sure the EGCS maintainers would welcome your patch...
Hit the egcs mailing list archives off of the egcs homepage. There is a long, long collection of threads about this problem, dealing especially with the Linux kernel. Linus Himself[tm] gets heavily involved.
Parts of it turn into a flamefest, but there /is/ a good deal of information down in there as well.
In any case, it's not a showstopping bug; you just have to use a flag.
The book Forever Peace by Joe Haldeman talks about this very subject. It's the driving point behind a very diverse plot; it gets pushed off to the side later, but provides the impetus for the characters to get into a hell of a mess.
> Or it could be the GOVERNMENT people > talking about the LATEST AND GREATEST > NUCLEAR TECHNOLOGY.
Um, no. I don't know which HBO movie you get your information from, but they're not that stupid. Sensitive information isn't discussed even over a normal landline, much less a cel phone.
Now, if you actually walk into a lab and start shootin' the breeze, then yeah, many times they ARE in fact that stupid. But they don't go jabbering over the commercial airwaves.
I for one say, sure, use encryption. There are going to be crooks out there trying to listen in. But don't blow it out of proportion and start insinuating that shoutcasts might be responsible for compromised classified data. Puh-leeze.
The "Cybercrime" infographic was also great. I was afraid that everybody had forgotten who Wintermute was... is... er, was. Talk about the future being inherited by robots!
Now if loading the Onion images would just stop crashing our browsers...
Slashdot Mirror
I didn't say that they shouldn't be bought. I said that they are overpriced. I think houses and cars are overpriced too, but I'm not advocating that we live in tents and walk thirty miles to work. I am definitely not saying that we should all go out and purchase cheaper IBMs.
We have a finite but nondeterministic number of Ultras here at work; four at the moment. I am well pleased with them. Occasionally there's an SGI machine, which is also nice but has a wacked-out library layout. But that's a different rant.
It's debatable. We have some of the vew SPARC V9 chips here where I admin, and they are verra verra nice. Also verra verra pricey.
Sun's biggest problem (and has been for some time) is that their hardware is way the hell overpriced, and their industry-standard stuff lags behind (e.g., their latest CDROM drives are a third the speed of a generic Plextor drive, but cost five times as much). Their custom hardware (UltraSPARC processors, say) is nice, but equally pricey.
There are some very handy things that you can do under Solaris/SPARC but not Solaris/x86. Even so, running on Intel whytanium will be a boost to Sun.
I would point out that running a spellchecker on the Taco Bell sign would have done /absolutely no good/.
I absolutely can't stand people who make mistakes like that (like the university newsletter reminding everyone that fire alarms are announced over "the pubic address system") and then complaining that "waaaah, but the spellchecker didn't catch it, it's not my fault." Yo, dumbass, "pubic" is spelled perfectly correctly.
Try using your $@!#?*@ brain instead of blindly clicking at a computer. The results can be amazing.
Oh, I didn't mean to imply that UNP is only an intro book. I bought the Second Edition because the First Edition and the APUE were so unbelievably useful.
I don't recall his website off the top of my head, but I think that uunet has a copy.
The latest (2nd) edition of _Unix Network Programming_ discusses IPv6. It's a really good introduction for somebody (like me) who knew jack-all about it to start with.
It's just technical enough that I can follow discussions about IPv6 implementation and management, but doesn't get into the really nasty details -- there are supposed to be other books for that, and _UNP_ has other topics to get to.
For the uninitiated, _Unix Network Programming, 2nd Edition_ is two or three volumes, all worth it, and written by the late W. Richard Stevens, Network God. RIP.
I think the games and "serious tools" have finally come full circle.
A much older gcc used to spawn nethack when it saw a programming construct that the authors didn't like. Now Doom spawns kill(1)/signal(2) when its users see a drooling, belching, fire-breathing construct that *they* don't like...
Ah, the great circle of life.
As a sysop for the Air Force Research Labs, I tell you straight up that I had nothing to do with it whatsoever. The fact that I now own massive shares of Sydney Opera House is a coincidence. Pay no attention to the man behind the curtain.
/.)
phil
(hoping that nobody else in his directorate reads
Several hard- and pseudo-hard-SF authors (e.g., Niven in several short stories, and Sterling in his recent _Distraction_ novel) have written stories involving an alternative application to the "listening to everything" scenario: devices which listen for the patterned sounds of a mugging, a rape, or gunfire. Then the police are called, or (assuming visual pattern recognition) the people involved are knocked out.
I for one want a small device to listen for the sounds of coworkers down the hall muttering, "Hmmm, maybe phil knows about this," and report it to me, so I can hide.
Has anybody ever seen a vendor offer transparent cases? Lots of folks make their own, but I've never heard of one off-the-shelf like that.
:-)
Dunno if I'd paint over it... having what appears to be a random collection of electronics under your arm or sitting on your desk can occasionally look neat. (I want internal parts that look like they're steam-powered, dammit.
I'm not certain about the "six lines" exactly, but Feynman was the person who discovered exactly why the O-rings on the Shuttle (STS) solid rocket boosters (SRBs) weren't doing their thing during the Challenger explosion.
I remember the first time I read some of the prefaces leading up to the Jargon File; the ones dealing with "hacker writing style" in particular. I recall being surprised/amused when I discovered that many of them were traits I had already acquired -- and then came upon ESR's comment that "we may see a revival of letter writing as an art form" (quoting from memory).
We'll have to carefully distinguish between words that have assigned power (legal documents) and words that have intrinsic power (religious texts, letters). What do you want to bet that there won't be any difference from the law's viewpoint? (Er, I guess. I'm rambling now.)
The letter is absolutely excellent reading, but I'm wondering about the first sentence of the sixth paragraph:
:-) What's to keep /every/ such key request from being "secret"? Is there provision in the bill such that certain extra circumstances must prevail in order for the demand itself to not be publicized?
"If the police ask you keep the demand to hand
over the key secret, telling anyone would
render you liable to 5 years in jail."
Perhaps somebody on the other side of the Pond could clear something up for this rebellious colonist.
That's a really good way of thinking about it. This begs the question: what happens to the environment (the project) when the number of inhabitants (the coders) outgrow it?
:-)
Obviously, a bunch of coders will leave to start work on a new/different project. But if they stay around instead of leaving, an amazing amount of damage would occur to whatever's being hacked on.
I can't think of any opensource projects off the top of my head that have been stripped down to tree bark and dust because there were too many coders. Anybody else?
(Halfway through rereading the Dune novels, so the whole ecology-as-culture thing is really stuck in my head right now.
Granted it's been years since I played with Linux, but when building a kernel we had to "make config," or something similar, which would ask the user what to include in the kernel (while remembering choices from last time, etc, etc).
/enough/ to be useful. But you used to be able to rip a significant amount of stuff out of the kernel.)
:-|
I'm assuming that today's distributions still do that, in some form or another. Why not just disable support for just about everything? It's what I used to do when building customized rescue diskettes. The resulting kernel got pretty small.
(Disclaimer: I don't know jack about embedded systems, and I don't know whether this process would bring the size down
The GPL is another problem altogether...
> As a point of caution to those about to grab
:)
> this latest scanner and joyride, every military
> installation & network is monitored 24/7. I
> assure you, portscans are detected and the
> source IP recorded & blocked. (To be specific,
> for 15 days after the attack/intrusion; if it
> occurs again, further measures are taken.)
Damn straight. I think our base blocks them for
longer than 15 days, though... that may just be
local extra paranoia. Not my baliwick, so I
could be wrong.
> But then, it's a research institution, and
> scientists don't like to sully their hands
> with such mundane matters.
When I worked on base before, I used to try and
make things convenient for my users as long as
security never got compromised. If they came and
complained, well, sorry, but that's the way
things have to be. Usually they understood.
Lately I've decided that I won't even listen to
"inconvenience" complaints. Screw 'em. My boxes
haven't been cracked yet, and I'm not going to
take any chances. So they have to go through
extra steps. Waaah.
+ Ok, what exactly does that do to the
:-) Yeah, the lack of preprocessed headers can really hurt once they stop changing, but like I said, I (and others) have been surprised at the difference some extra coding makes. Things like redundant include guards really do honestly work on a large project, and testing-in-isolation helps you to run that
:-), but I have to wonder whether distributing a compiler would be worth the overhead. Distributing the entire build, though, where each machine works on a different source file, is very cool, and is just the next logical step in "seperate compilation." Dunno about splitting the individual compilations of files... I wonder if/how Plan 9 does this.
+ compile/test/debug cycle. [...] that's where
+ the ~8min's+ per compile becomes penal.
Do you want the 8 minutes, or the 130 MB?
I was defending the binary size, not the compile times.
debug cycle much quicker, with tiny little testcases.
It also helps to set TMPDIR to a ramdisk.
+ Has anybody thought about a gcc based build
+ environment that can be distributed
I'm not an expert (yet, dammit
+ This is probably because of the lack of
+ precompiled headers. Much of the source
+ includes the headers to libs and system stuff.
Most probably. Without optimization, by far the
bulk of a compiler's time is spent parsing.
Without meaning to sound condescending, I must
at this point mention things like the redundant
include guards described in the Lakos text. I
found that the little extra typing really can
speed up the compliation stage significantly.
+ 4 Meg executable swells to a mindboggling
+ 130MB of god-knows-what nonsense when the
+ -g flag is on.
Speaking only for myself, not the EGCS people:
why do you care? It's the debugging version,
not the production version.
I realize that's harsh, but for the most part
my binary sizes don't get much attention from
me until after I turn off -g, enable a string
of space-saving optimizations, and then strip
the binary.
+ the current situation sucks for those of us
+ with beefy apps.
My last major project was beefy enough, and
egcs pulled through with flying colors for me.
If you have suggestions, I'm sure the EGCS
maintainers would welcome your patch...
Luck++;
Phil
Hit the egcs mailing list archives off of the
egcs homepage. There is a long, long collection
of threads about this problem, dealing especially
with the Linux kernel. Linus Himself[tm] gets
heavily involved.
Parts of it turn into a flamefest, but there
/is/ a good deal of information down in there as
well.
In any case, it's not a showstopping bug; you
just have to use a flag.
The book Forever Peace by Joe Haldeman talks about this very subject. It's the driving point behind a very diverse plot; it gets pushed off to the side later, but provides the impetus for the characters to get into a hell of a mess.
Good book, too. Won the Hugo for 1998.
> Or it could be the GOVERNMENT people
> talking about the LATEST AND GREATEST
> NUCLEAR TECHNOLOGY.
Um, no. I don't know which HBO movie you get
your information from, but they're not that
stupid. Sensitive information isn't discussed
even over a normal landline, much less a cel
phone.
Now, if you actually walk into a lab and start
shootin' the breeze, then yeah, many times they
ARE in fact that stupid. But they don't go
jabbering over the commercial airwaves.
I for one say, sure, use encryption. There are
going to be crooks out there trying to listen in.
But don't blow it out of proportion and start
insinuating that shoutcasts might be responsible
for compromised classified data. Puh-leeze.
The "Cybercrime" infographic was also great. I
was afraid that everybody had forgotten who
Wintermute was... is... er, was. Talk about the
future being inherited by robots!
Now if loading the Onion images would just stop
crashing our browsers...