It's just the "save icon". Maybe it doesn't look like anything anybody has ever seen but that doesn't prevent it from acquiring the necessary meaning.
Computers are full of anacronisms... My favorite is the strerror() output for ENOTTY (on some systems, probably pre-posix): "Not a typewriter". Well, duh...
All these dumb comments about "women's special needs" misses the point. The goal is to make something that's easy to use and not require a lot of fooling with to make it work as desired. Why not ask the opposite question: what's a "typical guy's printer"? If you make some overly broad sexist generalizations you would get: (1) doesn't connect with anything but a PC (who cares how hard it is to print photos from a camera, as long as there's some way to do it), (2) ugly (it's supposed to be functional not pretty), and (3) not ergonomic (we have big muscles for a reason - picking up awkwardly shaped boxes!).
Now that I think about it, the printer and its basic approach reminds me of something closer to home - the iMac and all its iPeripherals. The designers of the iMac weren't afraid to make something easy to use and nice looking. Does that make it a "women's computer"? Let all the female graphic designers and interior decorators have their cute Apples with the colors and rounded edges, and give us manly hackers our plain beige boxes with Linux and Windows, or black angular laptops that weigh 10 pounds! And our hard to use and ugly printers so we can reaffirm our testosterone!
The day the internet switched to TCP/IP was in '82 I think. You'd have to go look at the RFC's to find out when the spec first came out but it's reasonable to call TCP an 80's protocol.
Yeah, it's the wicked elbows that get you... But if you are just connecting different desktops in your house, what are you going to be doing that needs more than 10Mb/sec? I guess streaming uncompressed video from a server would, but who does that? Or maybe scientific computing or something where the machines need high bandwidth between them...
We had some work done and the contractors installed conduits as I requested but didn't put in pull-wires. There were some really awkward bends and I spent an hour trying to push the wire in using fish tape but I could never get it. Luckily there were some redundant paths and I gave up on that one. But the moral is to always get them to put in the pull wires for you...
Also, I found that by default, contractors seem use cat5 wire for phone connections. Keep in mind that 10base-T uses only 4 of the 8 strands and phones use 2. So if they forgot to wire up a room for data but did put in a phone jack you can easily convert that into a (slow) data connection and 2 phone lines.
It bothers me a bit that all the files are now in a big database. A good thing about CVS is that you can see what files and modules are available using regular unix tools, and if things get messed up in some way you can always fall back to the rcs commands or in the worst case edit the,v file by hand and extract the latest version. With a database, if things were to get corrupted enough (I have no evidence that this happens often, but still...) you are stuck. Just like with the windows registry, where if it gets messed up you lose big.
You mean like Microsoft already tried to do with Java and got sued by Sun? They have already shown themselves to be anti-Java and open-source won't make it easier for them.
In any case if you say "it will never work because somebody will kill it" then they don't even have to go to that trouble, since they have already won. I don't think it's so likely that they would succeed (not that they wouldn't try) but let's consider your second argument.
In the open source community now we have some who are pro-Mono because Microsoft is letting Mono development go forwards (and because it may be better, technically). Others are anti-Mono because (I assume) they don't trust Microsoft and they like Java better. But if Sun insists on selling key parts of Java for big $$$ how are you going to fight Mono which is free?
You can say "It's IE vs Netscape all over again!" but you can't complain because Microsoft lets other people reimplement technology that they might keep under control, but don't. They seem to be doing the right thing for once (if only because they feel that they can kill Java that way).
What IBM and ESR argue is that Sun is just cooperating in their own failure by not freeing up Java so it can compete with Mono. On the other hand, Sun might say "we're making money for now, why should we free up Java and stop making that money just so that a free Java can compete better with Mono?" It's strategic vs tactical thinking - profit today vs commercial viability in 5 years, and these days, publicly traded companies usually pick the first one.
C is pretty darn portable (if you do non-portable things like call system routines, that's not the case, of course).
When has it happened that an open-source language has become fragmented and incompatible? Perl? Tcl? Python?
Maybe the *BSD split some years back is an example of this. But in this case it seems clear that the egos of some of the participants took precedence over the common good. This also happened at a time when there was not as much at stake (BSD was small potatoes compared to Solaris, etc).
Has the Linux core fragmented? MySQL? GCC?
Well, okay, we do we xemacs vs GNU emacs. But these are rare exceptions.
This idea that open source = fragmentation and chaos is just Microsoft FUD.
I'd be happy to sell anybody, for a reasonable fee, a license to use any and all words that begin with Q... That is, I promise not to sue you if you have bought the license. Not to say that I would sue you or have any chance of winning if you didn't... But why take the chance?
Hey, I think there is a term for this... Let me think... Oh yeah, "extortion"...
I dare anybody to write obfusticated Python... Can't be done (at least in the spirit of the C and Perl cases)
Re:da vinci code, angels & demons, plus minor
on
Digital Fortress
·
· Score: 1
Yeah, the first time it was a nice twist. Now after reading his 3 other books I can spot the "surprise" bad guy from the first page he appears on. And that line in Angels and Demons, early on, about how you can slow yourself down in a fall with a big coat or something like that... I mean, foreshadowing is a good technique is used carefully but...
If you're spending several months looking for work, write some free software! If you are really lucky you will come up with something nice and useful and release it and your potential employers might have heard about it. In the worst case you can say, "Here's something I did recently, and you can have the source code to check it out". You probably can't say that about stuff you did at your previous jobs. Also it makes it clear that you are dedicated and enjoy programming, which counts for a lot.
Well, you obviously if you were part of the real world your hand would get sore pretty fast.
The decision that long==int32 is not something AMD did, it's something Microsoft did in the Win64 API. On linux long==int64 for Itanium at least - I don't know about AMD. But this is entirely a compiler option since the chip itself it happy to deal with int32 and int64 and couldn't care less whether the user typed long or int.
My guess would be that a lot of functions in the Win32 API are defined to take LONG values because they were written back in the day when int might be 16 bits. Microsoft wanted these arguments to continue to take 32-bit integers so they defined LONG to be 32 bits no matter what the pointer size is. You could argue that either they should not care how many bits these arguments are, or that they should have defined some other type from the start that they had better control over (i.e. changing it would not affect other people's code).
Anyway, whether you think people are idiots for assuming too much or not, you have to wonder why every other 64-bit OS since 1990 picked one option and Win64 picked the other one. Then again you could ask the same question about / vs \ which is still Microsoft's worst blunder, IMHO.
Of course you are right in a technical sense. Anybody who assumes more than is guaranteed is asking for trouble. But when all architectures for the last 15 years follow a certain pattern, people do write code that assumes things like that. What's the sense in breaking existing code that, while technically incorrect, works in all other environments? You are just shooting yourself in the foot by ensuring that porting to your system will be slow.
So now we have to port to IA32, IA64, AMD, and some other instruction set too? And we have to do separate ports for Windows, Linux, Solaris, HPUX, etc etc?? Guess which ones are going to get dropped because the industry says enough is enough! Itanium, because nobody has bought any machines, and the new Intel instruction set, if it's not 100% AMD compatible, because it's last in an already-crowded niche. IA32 will be the low-end architecture and AMD64 will be the high-end.
And Microsoft screwed up the long==void* assumption in Win64!! You'd think they would follow every other 64-bit system in the last 10 years that had sizeof (int) == 32, sizeof (long) == sizeof (void*) == 64. There is a lot of code that can't be easily ported to Win64 because of this stupidity.
Re:Not ambitious enough
on
Space Burial
·
· Score: 1
Nah.. people who run open relays do it because they don't know or haven't gotten around to fixing it. The threat of getting sued won't be any more of a deterrent than having their machines swamped by spammers.
My initial impression of XP (I haven't tried it but had it explained to me) is that it takes a lot of the fun and programmer-as-artist aspect out of software development. Also it is good for making a larger number of so-so programmers as productive as a few really good programmers.
However, most OSS projects seem to be labors of love by groups of individuals working together in their spare time. I would bet most of the largest contributors to OSS projects are very good programmers who don't need to be "managed" to the extent that XP does. I don't see how many of the XP ideas could be applied when none of the developers are in the same room on a regular basis (or even available to meet on-line at one time), their time commitments are unpredictable, and in many cases have big egos and work on what they feel like, not what the customers ask for... After all, programmers have day jobs that are like that!
First of all there is no such thing as a typical program... If you are writing a lisp interpreter where everything is a pointer then you may see your memory usage almost double. If you have a numerical program that is dominated by huge arrays of floats you might not see any difference at all.
Second, here is a trick I have seen - it seems a bit strange but works well if you encapsulate your data well. Keep in mind that objects are generally aligned to a 8-byte boundary (if they are malloc'ed). That means your low 3 bits are not used at all. If your objects have, say, 64 bytes of data in them (possibly after a bit of padding) then you are wasting 6 bits. Just store your pointers as 32-bit words, shifted over by 6 bits. When you want to dereference them, your get-the-pointer accessor function just shifts them back and gives you a 64-bit pointer.
Now you have an effective address space of 256GB and your data size has not grown at all. Maybe you have taken a hit in performance but until you benchmark you never know...
It sounds like you did exactly what you were supposed to do. Isn't part of the point of a training exercise that the danger is real and freak accidents like that can happen? Maybe the real mistake was not having an emergency backup communication system (and the same would apply for a real conflict situation).
Also, hidden Markov models (which are used for phylogenetic analysis and involve Bayesian statistics) have been used longest in speech recognition.
It's just the "save icon". Maybe it doesn't look like anything anybody has ever seen but that doesn't prevent it from acquiring the necessary meaning.
Computers are full of anacronisms... My favorite is the strerror() output for ENOTTY (on some systems, probably pre-posix): "Not a typewriter". Well, duh...
All these dumb comments about "women's special needs" misses the point. The goal is to make something that's easy to use and not require a lot of fooling with to make it work as desired. Why not ask the opposite question: what's a "typical guy's printer"? If you make some overly broad sexist generalizations you would get: (1) doesn't connect with anything but a PC (who cares how hard it is to print photos from a camera, as long as there's some way to do it), (2) ugly (it's supposed to be functional not pretty), and (3) not ergonomic (we have big muscles for a reason - picking up awkwardly shaped boxes!).
Now that I think about it, the printer and its basic approach reminds me of something closer to home - the iMac and all its iPeripherals. The designers of the iMac weren't afraid to make something easy to use and nice looking. Does that make it a "women's computer"? Let all the female graphic designers and interior decorators have their cute Apples with the colors and rounded edges, and give us manly hackers our plain beige boxes with Linux and Windows, or black angular laptops that weigh 10 pounds! And our hard to use and ugly printers so we can reaffirm our testosterone!
The day the internet switched to TCP/IP was in '82 I think. You'd have to go look at the RFC's to find out when the spec first came out but it's reasonable to call TCP an 80's protocol.
Yeah, it's the wicked elbows that get you... But if you are just connecting different desktops in your house, what are you going to be doing that needs more than 10Mb/sec? I guess streaming uncompressed video from a server would, but who does that? Or maybe scientific computing or something where the machines need high bandwidth between them...
We had some work done and the contractors installed conduits as I requested but didn't put in pull-wires. There were some really awkward bends and I spent an hour trying to push the wire in using fish tape but I could never get it. Luckily there were some redundant paths and I gave up on that one. But the moral is to always get them to put in the pull wires for you...
Also, I found that by default, contractors seem use cat5 wire for phone connections. Keep in mind that 10base-T uses only 4 of the 8 strands and phones use 2. So if they forgot to wire up a room for data but did put in a phone jack you can easily convert that into a (slow) data connection and 2 phone lines.
1/4 cent increases are big?? My bill goes up by $1 every month, it seems...
It bothers me a bit that all the files are now in a big database. A good thing about CVS is that you can see what files and modules are available using regular unix tools, and if things get messed up in some way you can always fall back to the rcs commands or in the worst case edit the ,v file by hand and extract the latest version. With a database, if things were to get corrupted enough (I have no evidence that this happens often, but still...) you are stuck. Just like with the windows registry, where if it gets messed up you lose big.
Any opinions on this?
Does NZ now have the record for the most Oscars per-capita?
You mean like Microsoft already tried to do with Java and got sued by Sun? They have already shown themselves to be anti-Java and open-source won't make it easier for them.
In any case if you say "it will never work because somebody will kill it" then they don't even have to go to that trouble, since they have already won. I don't think it's so likely that they would succeed (not that they wouldn't try) but let's consider your second argument.
In the open source community now we have some who are pro-Mono because Microsoft is letting Mono development go forwards (and because it may be better, technically). Others are anti-Mono because (I assume) they don't trust Microsoft and they like Java better. But if Sun insists on selling key parts of Java for big $$$ how are you going to fight Mono which is free?
You can say "It's IE vs Netscape all over again!" but you can't complain because Microsoft lets other people reimplement technology that they might keep under control, but don't. They seem to be doing the right thing for once (if only because they feel that they can kill Java that way).
What IBM and ESR argue is that Sun is just cooperating in their own failure by not freeing up Java so it can compete with Mono. On the other hand, Sun might say "we're making money for now, why should we free up Java and stop making that money just so that a free Java can compete better with Mono?" It's strategic vs tactical thinking - profit today vs commercial viability in 5 years, and these days, publicly traded companies usually pick the first one.
C is pretty darn portable (if you do non-portable things like call system routines, that's not the case, of course).
When has it happened that an open-source language has become fragmented and incompatible? Perl? Tcl? Python?
Maybe the *BSD split some years back is an example of this. But in this case it seems clear that the egos of some of the participants took precedence over the common good. This also happened at a time when there was not as much at stake (BSD was small potatoes compared to Solaris, etc).
Has the Linux core fragmented? MySQL? GCC?
Well, okay, we do we xemacs vs GNU emacs. But these are rare exceptions.
This idea that open source = fragmentation and chaos is just Microsoft FUD.
I'd be happy to sell anybody, for a reasonable fee, a license to use any and all words that begin with Q... That is, I promise not to sue you if you have bought the license. Not to say that I would sue you or have any chance of winning if you didn't ... But why take the chance?
Hey, I think there is a term for this... Let me think... Oh yeah, "extortion"...
I dare anybody to write obfusticated Python ... Can't be done (at least in the spirit of the C and Perl cases)
Yeah, the first time it was a nice twist. Now after reading his 3 other books I can spot the "surprise" bad guy from the first page he appears on. And that line in Angels and Demons, early on, about how you can slow yourself down in a fall with a big coat or something like that... I mean, foreshadowing is a good technique is used carefully but ...
If you're spending several months looking for work, write some free software! If you are really lucky you will come up with something nice and useful and release it and your potential employers might have heard about it. In the worst case you can say, "Here's something I did recently, and you can have the source code to check it out". You probably can't say that about stuff you did at your previous jobs. Also it makes it clear that you are dedicated and enjoy programming, which counts for a lot.
Well, you obviously if you were part of the real world your hand would get sore pretty fast.
The decision that long==int32 is not something AMD did, it's something Microsoft did in the Win64 API. On linux long==int64 for Itanium at least - I don't know about AMD. But this is entirely a compiler option since the chip itself it happy to deal with int32 and int64 and couldn't care less whether the user typed long or int.
My guess would be that a lot of functions in the Win32 API are defined to take LONG values because they were written back in the day when int might be 16 bits. Microsoft wanted these arguments to continue to take 32-bit integers so they defined LONG to be 32 bits no matter what the pointer size is. You could argue that either they should not care how many bits these arguments are, or that they should have defined some other type from the start that they had better control over (i.e. changing it would not affect other people's code).
Anyway, whether you think people are idiots for assuming too much or not, you have to wonder why every other 64-bit OS since 1990 picked one option and Win64 picked the other one. Then again you could ask the same question about / vs \ which is still Microsoft's worst blunder, IMHO.
Of course you are right in a technical sense. Anybody who assumes more than is guaranteed is asking for trouble. But when all architectures for the last 15 years follow a certain pattern, people do write code that assumes things like that. What's the sense in breaking existing code that, while technically incorrect, works in all other environments? You are just shooting yourself in the foot by ensuring that porting to your system will be slow.
So now we have to port to IA32, IA64, AMD, and some other instruction set too? And we have to do separate ports for Windows, Linux, Solaris, HPUX, etc etc?? Guess which ones are going to get dropped because the industry says enough is enough! Itanium, because nobody has bought any machines, and the new Intel instruction set, if it's not 100% AMD compatible, because it's last in an already-crowded niche. IA32 will be the low-end architecture and AMD64 will be the high-end.
And Microsoft screwed up the long==void* assumption in Win64!! You'd think they would follow every other 64-bit system in the last 10 years that had sizeof (int) == 32, sizeof (long) == sizeof (void*) == 64. There is a lot of code that can't be easily ported to Win64 because of this stupidity.
Sundiver by David Brin? That's a similar idea
Nah.. people who run open relays do it because they don't know or haven't gotten around to fixing it. The threat of getting sued won't be any more of a deterrent than having their machines swamped by spammers.
My initial impression of XP (I haven't tried it but had it explained to me) is that it takes a lot of the fun and programmer-as-artist aspect out of software development. Also it is good for making a larger number of so-so programmers as productive as a few really good programmers.
However, most OSS projects seem to be labors of love by groups of individuals working together in their spare time. I would bet most of the largest contributors to OSS projects are very good programmers who don't need to be "managed" to the extent that XP does. I don't see how many of the XP ideas could be applied when none of the developers are in the same room on a regular basis (or even available to meet on-line at one time), their time commitments are unpredictable, and in many cases have big egos and work on what they feel like, not what the customers ask for... After all, programmers have day jobs that are like that!
First of all there is no such thing as a typical program... If you are writing a lisp interpreter where everything is a pointer then you may see your memory usage almost double. If you have a numerical program that is dominated by huge arrays of floats you might not see any difference at all.
Second, here is a trick I have seen - it seems a bit strange but works well if you encapsulate your data well. Keep in mind that objects are generally aligned to a 8-byte boundary (if they are malloc'ed). That means your low 3 bits are not used at all. If your objects have, say, 64 bytes of data in them (possibly after a bit of padding) then you are wasting 6 bits. Just store your pointers as 32-bit words, shifted over by 6 bits. When you want to dereference them, your get-the-pointer accessor function just shifts them back and gives you a 64-bit pointer.
Now you have an effective address space of 256GB and your data size has not grown at all. Maybe you have taken a hit in performance but until you benchmark you never know...
Ha ha, everybody has done that at one point in their careers....
It sounds like you did exactly what you were supposed to do. Isn't part of the point of a training exercise that the danger is real and freak accidents like that can happen? Maybe the real mistake was not having an emergency backup communication system (and the same would apply for a real conflict situation).