It looks like you didn't read either article you mentioned. RTFA! Neither bill mandates OSS, both bills mandate considering OSS. The basic problem is most managers don't actively look for good solutions, but wait for marketing droids to come to them ad harass them. OSS rarely sends marketing droids, so managers make under-informed decissions. Both bills are about forcing managers to get off their asses and consider options that don't come and harass them. It's about more informed choices and increasing choice, not limiting choice.
I don't think either OSS or open formats should be mandated. They should be considered, and perhaps non-open format options should need explicit justification inpurchase decissions. Forcing people to be informed seldom hurts. Legislators micro-managing purchase decissions across the board is a bad precident to start.
Open file formats are also much less cut-and-dry than open source. You can wrap a word document in XML and call it an open file format, or even break up the data structures and put them in XML tags but leave them incomprehensible. "Open format" is not well defined.
The parent's poster failed to read either article he mentioned in his post. Parent is just plain wrong. Parent should go directly to jail, not passing go, not collecting $200.
If you want case insensitivity and "better" names for directories, then do that in the shell/GUI file browser. Things are aranged the way they are for good reasons. (As my sibling posts have pointed out.) Give the user a nice gui and maybe a nice shell that will automagically resolve case problems. No need to do that in the fs.
All of the problems you see are UI problems and should be taken care of in the UI layer. I believe the best thing about *NIX is its seperation of duties and layers. No need to make *NIX more like windows in the respect of mixing layers. Fix UI problems in the UI and let the fs be the best FS it can be. Oh, and there is support for FAT16/32 and other case-insensitive FSes in *NIX. I believe the driver converts all of the paths to upper case. Maybe tab-completion in your shell doesn't work the way you want, but then you should fix the shell.
Others have pointed out most of the other flaws in your proposal. Hard-coding should be considered a bug, etc. People will ignore your suggestion for environemnt varibles just as much as they ignore good design practice now.
You should look at Plan9. Each user has a custom view of the filesystem, kind of like chrooting every user, but much more elegant. You could implement your proposal that way if you wanted and it would indeed be more elegant than the *NIX single-rooted fs. However, your proposal makes changes at the wrong layer. Move up or two in the layers of abstraction. You're too used to windows where it's painfully obvious which "drive" your files are on. Under *NIX, if you care you can type "df" and see what's mounted where, butoterwise you don't know which physical volume your data is on, nor should you. Think abstraction layers. They make things cleaner and more flexible.
No, they just added yet another prefix, this way they can mix regular x86 instructions and x86-64 instructions.
Yes it is another kludge, which will increase the code size of x86-64 code, but at least it gives you 16 registers.
Too bad. Constant width instructions would have meant they could start decoding an arbitrary number of instructions ahead without partially decoding any of the preceding instructions. As long as you're willing to to throw out 2/3 of your instruction decodings, you can also do the same with the current 3-length (1,2, or 3 bytes) system. Even on x86, which allows unaligned memory acess, aligned meory acess is faster.
The ARM "thumb" instruction set gets away with 16-bit instructions with 16 registers. Maybe getting down to 256 operations is too high a price to pay, so they'd go with 16-bit and 32-bit instructions. Sticking to 2-byte and 4-byte instructions means your loads are aligned and your instrcuctions never wrap across cache lines. The 8087 FP instructions don't work in 64-bit mode. Are all of the other x86 instructions functional in 64-bit mode?
I assume they wanted people to still be able to use their old 32-bit binary-only libraries linked with 64-bit code. How costly is a mode change to/from 64-bit mode? I trust AMD to make the design clean enough that a mode change only involves a change in the decoder unit.
Unless they include a simplified kerberos implementation (with sequence numbers making replays impossible) on the NIC, they're in for trouble and lots of it.
1)Get into one machine behind firewall.
2)Sniff database's possibly encrypted RDMA setting your account to zero balance.
3)...
4)Profit!!! (Replay the message setting your account balance back to zero before you get billed.)
The Alpha was the first CPU to 500 MHz (right?), and stayed competitive with x86 long after it got passed in clock speed. x86 is so good today because of the tremendous amount of research money its sales volume generates. Alpha provided much more bang for the research buck. They simply looked at what sorts of instructions are easy for compilers to utilize and designed a CPU around that. (It also helped that from the get-go they decided all Alphas were going to be purely 32+64-bit RISC chips. They had none of this stuff with IBM now supporting 3 different but closely related instruction sets on the POWER/PPC chips.) Are there any compilers that output x86 BCD arithmetic instructions anymore? AMD got rid of the 8087 mess in x86-64-bit mode. Maybe eventually they'll release a 64-bit-mode-only x86 CPU with a 8-16-32-bit mode emulation library.
In 64-bit mode, do they finally use constant-width instructions or at least limit themselves to 2-byte and 4-byte instructions? AMD has done some very smart things with x86, like 3DNow being much cleaner than MMX. I hope they continue to do nice clean things with the x86 instruction set (and depricate the kludge).
Maybe they just wanted a second option. Hardware emulation probably runs some apps faster and software emulation probably runs others faster.
IMHO, the software emulator is a better long-term solution. A hardware emulator uses some power even if you're not using it and drives up the cost of the chips by taking up realestate and increasing the defect rate. Your design-test cycle is also much faster for a software solution. There's also the marketing point of "we're doing this well so far, and will give you an even better version when it comes out, for free". They can't easily upgrade hardware for free at a later date. The software emulator probably has a lot of overlap with the compiler group, so you might get compiler research almost for free.
Also, I assume most of the guys writing the software emulator aren't experts in hardware design and vice-versa. The two projects are completely independent and likely don't steal personell from eachother.
So is his much-hyped much-secret Fortuna pseudorandom number generator just another Yarrow implementation, an evolutionary step beyond Yarrow-160? He seems to not have any specs online...
From the table of contents of the book, it looks like it could be just another member of the Yarrow family.
If you would be so kind as to let me try and interpret what the parent post was trying to say:
OpenBSD is legendary for its security-centric development process. There are also projects like TrustedBSD (based on FreeBSD, IIRC) and SELinux, as well as analysis tools such as bastille. EROS, Flux/Fluke, and to some extent Plan 9 all have some interesting security features. What do you see as the pros/cons of each of the "finalist" OSes/designs/approaches for the Crunch Box and how was your final decission on OpenBSD reached?
On a personal note, I think the answer will be much less involved than the parent poster thinks. OpenBSD has legendary code review and security practices. If only the package system integrated signatures with the tar balls, and ports were signed:-( I'm not sure about mandatory acess controls in OpenBSD. I'm sure someone has ported them from TrustedBSD.
... is what you get when some movie industry PHBs misread Applied Cryptography. Ohh... we can get away with smaller keys if we use Epilepsy to our advantage? Let's go for it!
I'd be worried. The movie industry hires some real idiots. DVD encryption turns out to be about 16-bits strong if you use a simplified version of the attack Ross Andersen discovered against GSM cellphones. The GSM A4 break was known before DVD encryption was released. You don't actually need the cracked player keys if you're willing to wait a couple of seconds to bruit force the disk key.
In short, I wouldn't trust the jokers the movie industry hires. Research shortcuts with epililepsy and retinal damage on the table spells bad news. That, and for the cost of you and your date going to the movie, you can BUY a known great DVD and snuggle on the couch at home rather than sit next to a bunch of strangers in uncomfortable seats. (Or if you're like a friend of mine and are morally opposed to giving one red cent to the MPAA, you could grab a good movie off Kazaa and give the DVD purchase cost to charity.)
and deny them the ability to make a decent honest living, where's their incentive to behave?
If the person shows good solid evidence of being reformed, I don't see what the problem is. If they got caught once, they certainly no longer feel invincible. They know the consequences and the ease of getting caught more than Joe Random.
With slightly different role models and peer pressure in jr.high/early high school, I could definately see myself getting into lots of mischeif just for the curiosity of the thing. I think any reasonably intelligent and curious youth could have found him/herself in Mitnick's shoes. It's easy to screw up at an early age and keep in old patterns. Few people self-reform.
Iif you personally don't want to take a chance on a one-time convict, don't prevent others from taking the chance.
Back in 1997, my MIT fraternity house had a/16 network in a house zoned to house 22 people. That's about 3,000 IP addresses per person or 16 IP addresses per square foot (a very crowded house, we moved to a much bigger house later). This is probably a world record for IPv4 address density. (The MIT low-cost residence might have beat us.) It appears that MIT has gone to routing only two/24s to the house now and left the other 254/24s unallocated.
Some countries only get a sinle/24 network. The IPv4 space is full of huge differences in per capita allocations. There are tons of cases where huge corporations and universities have hundreds or thousands of times more unused addresses than used addresses. IPv4 routing tables would get unmanageable if you tried finer grained allocation, but there is little objective reason why MIT needs 16 million public IP addresses. When you have several hundred IP addresses per person, it's no wonder the MIT Media Lab comes up with ideas like IP-enabled tennis shoes.
We really have no idea what the computing environments will be like in 100 years, nor what the core uses of computers will be. I think hoping to use languges "along that evolutionary path" is putting the cart before the horse. I think 25-years is about as far ahead as you can reasonably hope to predict. It's like a 1-week forecast. Nobody asks the weather channel for a 1-month forecast, as the margin of error becomes astronomical.
One poster claimed quantum computing will make current languaes useless. This is false. Any reasonably flexible language has space for new data types and operators. You would have to be careful not to prematurely branch based on a quantum value, as this may force you to opserve its value, destroying the superposition. However, I don't doubt Fortran will be one of the first languages used in quantum computing once they get past the assebly language stage.
What will languages be like in 25 years (and maybe 50 years)?
Well, there will be a Fortran and a Lisp and a C (maybe a C++). Lisp has always had automatic garbage collection. The Fortran and the C will have optional garbage colletors. Fortran, Lisp, and C are all decent attempts at languages that are pretty easy to grasp and have huge legacy backings.
Hopefully all of the main languages will be less machine depenent. Fixnums, ints, longs, floats, and doubles will be the same size across platforms, wasting a few cycles if this doesn't fit the underlying hardware.
In terms of new novel languages, I see languages simultaneously going three ways. I forsee languages that resemble formal proofs and/or formal specifications for use where reliability is critical. I forsee languages specialized for Scientific/Engineering disciplines. (Maybe Fortran, Excell, and Matlab cover all of the bases well enough, but I hope there is enough room left for improvement to drive innovation and adoption. Having a CS background, I didn't appreciate LabView's "G" language until I had an opportunity to see the ugly ugly code scientists and engineers tend to write in Fortran.) (I can also imagine efforts to use sytaxts that better express parallelism and other features for optimimizers/compilers so we finally have a widely used scientific/engineering language that is faster than Fortran 77. I can also see more languages like the Bell Labs Aleph, designed for parallel/cluster environments.) The third direction I see languages going is scripting/prototyping-like languages that will look more like natural language. (It's too bad there isn't a cross-platform open-soource AppleScript-like language yet.)
What do I think languages should have? Languages should have garbage collection and bounds checking enabled by default (of course, optionally turned off if you really must have the performance).
Langages should have very clean and consitent APIs. Having few orthagonal types helps make a language clean Languages should merge character arrays and strings (arguably the Algol languages have had this for a while). If a language wants to be able to have immutable strings, it should provide a way to declair an immutable variant of each fundamental type. (This is actually very useful in writing less buggy code.) Languages should strictly define the size of fundametal numeric types. (I really like Python, but it seems a huge mistake that an integer is "at least 32-bits". Allowig variations in size of fundametal numeric types adds cross-platform bugs. If I wrote a language, the types would look like "int32" "int64" "float32", "float64", "complex32" and "complex64". We got rid of 9- and 12-bit bytes. We should further get rid of these headaches.) Having worked with lots of engineers and scientists, I would love to see complex numbers as basic numeric types that all of the normal operators work on. Wrapping two doubles in an object adds a function call overhead for each numeric operation. Performance with complex numers (and numbers in general) is one big reason a lot of the code I see is written in F
You'll need ab bootloader such as GRUB to boot emacs, unles they've fnished implementing C-x boot;-)
If you like XEmacs, you'll also need X11 and an official OS.
BTW, where is ctrl on a German keyboard? I was in Germany a couple of weeks ago composing email in an internet cafe and got done composing the email only to discover I couldn't C-x C-s, C-x C-c.
The limitations on liability established by this section shall apply to a service provider only if the service provider -
(A) has adopted and reasonably implemented, and informs subscribers and account holders of the service provider's system or network of, a policy that provides for the termination in appropriate circumstances of subscribers and account holders of the service provider's system or network who are repeat infringers; and
Uhh... so does Google need to implement a way to block access to its service to people that are habitual copyright infringers? I'd love to see someone get the (MP/RI)AA banned from all major search engines by showing habitual copyright infringement from behind their NAT boxes. (In any good sized organization, you'll find infringement.)
I can see a GUI packge/ports manager, but you have all of about 8 options in the installer. A GUI instller would be larger and more error prone. I've used GRUB to boot OpenBSD and it works fine, although it's a bit much for just a bootloader.
The guy knew the risks he was taking by having an affair. If trade secrets were accidently mailed, I'm not sure how I'd react. It's one thing to correct mistakes, it's another to actively protect immorality. I'd leave the decission about the email up to Simon, and not interfering in the situation. (Deleting the email or forwarding the email to the wife would both be interfering in the situation.)
Caller: "Umm, I accidently emailed my plot to kill my wife to a co-worker instead of my lover. Could you please delete it?" Of course, this example assumes you believe murder is amoral and only sheds light on the previous case if you also believe adultery is amoral.
Actually, random is much better than zeros. There are also some patterns you should write over the hard drive before writting the random data (based on the way the HD actually stores data to disk). People actually do research on how to recover/prevent recovery of files.
A known overwrite history helps in interpreting residual data. The usual way people in the know suggest overwriting the HD is to use/dev/random to generate an encrypion key, then create an encrypted block device (say, by using an encryptd loopback device) using that key, then writing encrypted zeros to the disk. Wash, rinse, repeat.
Note that overwriting the entire disk several times is a big stress on the drive. I've killed
two hard drives during secure deletion of content. I suspect it was a heating problem. Cheap OEM HDs aren't designed to undergo contant writes for hours on end several years after manufacture. Then again, maybe I just have bad luck.
Random data should give you the worst compression ratio, but not necessarily speed. bzip2 starts out by using a poor compression agorithm (RLE) before the BWT becuse the worst case for the bwt is all of the bytes being the same. The BWT actually runs very fast with random inputs compared to all zeros, for instance.
I have no idea what lewd or lascivious means in terms of cohabitation.
It's probably there to distinguish platonic coed residences from romantic unmarried cohabitation. It would appear to be legal to live with someone of the oposite sex as long as there is no naked fun involved.
I have two female apartment mates. They sleep in a seperate room from me. I have never been romantical involved with either of them by any stretch of the imagination (well, unless you count my ex GF's imagination). If I was in Michigan and that clause wasn't in there, that would be yet another law hanging over my head.
He wasn't talking about Brownian motion or other vibrational motion of atoms, but about electrons orbiting nuclei. This isn't heat. At absolute zero, the elctrons would still orbit the nucleus.
However, the grandparent poter should RTFA. This is perpetual motion, but not a perpetual motion machine because it cannot be used to do work indefinately. The specific case of atoms is discussed in TFA.
They both support free speech. I was just responding to someone that was disgusted that supposedly there is kiddy porn (which I don't doubt) two degrees of seperation away from the official Freenet client start page. I was just saying that some days I consider the Freedom Engine admirable. Most days I wouldn't link without judgement to stuff I disagree with just for the sake of free speech. It takes a lot of character to believe in free speech that strongly, and some guy was really cutting down the Freedom Engine for it. He then refused to use the official Freenet client becuase it linked to the Freedom Engine.
I'm not sure which directories GNUnet links to directly. GNUnet certainly doesn't censor any content, so you can get the same stuff through that client. My point was simply that anyone claiming to support free speech shouldn't throw out the entire official freenet client because the directory they link to links to everything under the sun, including kiddie porn. You could probably Google for kiddie porn and find some, but very few people boycot Mozilla becuase it uses Google as its default search engine.
The reuters reporters can't see any wells burning from where they are with their equipment. Maybe they're expecting the 3-4 burning wells to look like the 700 Saddam torched in 1991. Maybe the US satelites also have a better view than the reporters.
The Reuters reporters didn't say there aren't burning oil wells. They say they can't see any. Maybe the U.S. is lying, but realize that the reporters aren't contradicting the official U.S. story. If the reporters were roaming around the oil fields looking for the handful that are said to be burning, that would be a different story.
Energy must be thrown away in any system consuming energy at steady state. See second law of thermodynamics.
If you put a heat engine on the CPU, you reduce energy transfer versus a heatsink/heatpipe. You coul recover a small percentage of the power, but it's really not worth it.
Slashdot Mirror
I don't think either OSS or open formats should be mandated. They should be considered, and perhaps non-open format options should need explicit justification inpurchase decissions. Forcing people to be informed seldom hurts. Legislators micro-managing purchase decissions across the board is a bad precident to start.
Open file formats are also much less cut-and-dry than open source. You can wrap a word document in XML and call it an open file format, or even break up the data structures and put them in XML tags but leave them incomprehensible. "Open format" is not well defined.
The parent's poster failed to read either article he mentioned in his post. Parent is just plain wrong. Parent should go directly to jail, not passing go, not collecting $200.
All of the problems you see are UI problems and should be taken care of in the UI layer. I believe the best thing about *NIX is its seperation of duties and layers. No need to make *NIX more like windows in the respect of mixing layers. Fix UI problems in the UI and let the fs be the best FS it can be. Oh, and there is support for FAT16/32 and other case-insensitive FSes in *NIX. I believe the driver converts all of the paths to upper case. Maybe tab-completion in your shell doesn't work the way you want, but then you should fix the shell.
Others have pointed out most of the other flaws in your proposal. Hard-coding should be considered a bug, etc. People will ignore your suggestion for environemnt varibles just as much as they ignore good design practice now.
You should look at Plan9. Each user has a custom view of the filesystem, kind of like chrooting every user, but much more elegant. You could implement your proposal that way if you wanted and it would indeed be more elegant than the *NIX single-rooted fs. However, your proposal makes changes at the wrong layer. Move up or two in the layers of abstraction. You're too used to windows where it's painfully obvious which "drive" your files are on. Under *NIX, if you care you can type "df" and see what's mounted where, butoterwise you don't know which physical volume your data is on, nor should you. Think abstraction layers. They make things cleaner and more flexible.
Too bad. Constant width instructions would have meant they could start decoding an arbitrary number of instructions ahead without partially decoding any of the preceding instructions. As long as you're willing to to throw out 2/3 of your instruction decodings, you can also do the same with the current 3-length (1,2, or 3 bytes) system. Even on x86, which allows unaligned memory acess, aligned meory acess is faster.
The ARM "thumb" instruction set gets away with 16-bit instructions with 16 registers. Maybe getting down to 256 operations is too high a price to pay, so they'd go with 16-bit and 32-bit instructions. Sticking to 2-byte and 4-byte instructions means your loads are aligned and your instrcuctions never wrap across cache lines. The 8087 FP instructions don't work in 64-bit mode. Are all of the other x86 instructions functional in 64-bit mode?
I assume they wanted people to still be able to use their old 32-bit binary-only libraries linked with 64-bit code. How costly is a mode change to/from 64-bit mode? I trust AMD to make the design clean enough that a mode change only involves a change in the decoder unit.
1)Get into one machine behind firewall.
2)Sniff database's possibly encrypted RDMA setting your account to zero balance.
3)...
4)Profit!!! (Replay the message setting your account balance back to zero before you get billed.)
In 64-bit mode, do they finally use constant-width instructions or at least limit themselves to 2-byte and 4-byte instructions? AMD has done some very smart things with x86, like 3DNow being much cleaner than MMX. I hope they continue to do nice clean things with the x86 instruction set (and depricate the kludge).
IMHO, the software emulator is a better long-term solution. A hardware emulator uses some power even if you're not using it and drives up the cost of the chips by taking up realestate and increasing the defect rate. Your design-test cycle is also much faster for a software solution. There's also the marketing point of "we're doing this well so far, and will give you an even better version when it comes out, for free". They can't easily upgrade hardware for free at a later date. The software emulator probably has a lot of overlap with the compiler group, so you might get compiler research almost for free.
Also, I assume most of the guys writing the software emulator aren't experts in hardware design and vice-versa. The two projects are completely independent and likely don't steal personell from eachother.
From the table of contents of the book, it looks like it could be just another member of the Yarrow family.
If this thing gets too popular without proper throttling, they could cause real havoc.
OpenBSD is legendary for its security-centric development process. There are also projects like TrustedBSD (based on FreeBSD, IIRC) and SELinux, as well as analysis tools such as bastille. EROS, Flux/Fluke, and to some extent Plan 9 all have some interesting security features. What do you see as the pros/cons of each of the "finalist" OSes/designs/approaches for the Crunch Box and how was your final decission on OpenBSD reached?
On a personal note, I think the answer will be much less involved than the parent poster thinks. OpenBSD has legendary code review and security practices. If only the package system integrated signatures with the tar balls, and ports were signed :-( I'm not sure about mandatory acess controls in OpenBSD. I'm sure someone has ported them from TrustedBSD.
I'd be worried. The movie industry hires some real idiots. DVD encryption turns out to be about 16-bits strong if you use a simplified version of the attack Ross Andersen discovered against GSM cellphones. The GSM A4 break was known before DVD encryption was released. You don't actually need the cracked player keys if you're willing to wait a couple of seconds to bruit force the disk key.
In short, I wouldn't trust the jokers the movie industry hires. Research shortcuts with epililepsy and retinal damage on the table spells bad news. That, and for the cost of you and your date going to the movie, you can BUY a known great DVD and snuggle on the couch at home rather than sit next to a bunch of strangers in uncomfortable seats. (Or if you're like a friend of mine and are morally opposed to giving one red cent to the MPAA, you could grab a good movie off Kazaa and give the DVD purchase cost to charity.)
If the person shows good solid evidence of being reformed, I don't see what the problem is. If they got caught once, they certainly no longer feel invincible. They know the consequences and the ease of getting caught more than Joe Random.
With slightly different role models and peer pressure in jr.high/early high school, I could definately see myself getting into lots of mischeif just for the curiosity of the thing. I think any reasonably intelligent and curious youth could have found him/herself in Mitnick's shoes. It's easy to screw up at an early age and keep in old patterns. Few people self-reform.
Iif you personally don't want to take a chance on a one-time convict, don't prevent others from taking the chance.
Some countries only get a sinle /24 network. The IPv4 space is full of huge differences in per capita allocations. There are tons of cases where huge corporations and universities have hundreds or thousands of times more unused addresses than used addresses. IPv4 routing tables would get unmanageable if you tried finer grained allocation, but there is little objective reason why MIT needs 16 million public IP addresses. When you have several hundred IP addresses per person, it's no wonder the MIT Media Lab comes up with ideas like IP-enabled tennis shoes.
One poster claimed quantum computing will make current languaes useless. This is false. Any reasonably flexible language has space for new data types and operators. You would have to be careful not to prematurely branch based on a quantum value, as this may force you to opserve its value, destroying the superposition. However, I don't doubt Fortran will be one of the first languages used in quantum computing once they get past the assebly language stage.
What will languages be like in 25 years (and maybe 50 years)?
Well, there will be a Fortran and a Lisp and a C (maybe a C++). Lisp has always had automatic garbage collection. The Fortran and the C will have optional garbage colletors. Fortran, Lisp, and C are all decent attempts at languages that are pretty easy to grasp and have huge legacy backings.
Hopefully all of the main languages will be less machine depenent. Fixnums, ints, longs, floats, and doubles will be the same size across platforms, wasting a few cycles if this doesn't fit the underlying hardware.
In terms of new novel languages, I see languages simultaneously going three ways. I forsee languages that resemble formal proofs and/or formal specifications for use where reliability is critical. I forsee languages specialized for Scientific/Engineering disciplines. (Maybe Fortran, Excell, and Matlab cover all of the bases well enough, but I hope there is enough room left for improvement to drive innovation and adoption. Having a CS background, I didn't appreciate LabView's "G" language until I had an opportunity to see the ugly ugly code scientists and engineers tend to write in Fortran.) (I can also imagine efforts to use sytaxts that better express parallelism and other features for optimimizers/compilers so we finally have a widely used scientific/engineering language that is faster than Fortran 77. I can also see more languages like the Bell Labs Aleph, designed for parallel/cluster environments.) The third direction I see languages going is scripting/prototyping-like languages that will look more like natural language. (It's too bad there isn't a cross-platform open-soource AppleScript-like language yet.)
What do I think languages should have? Languages should have garbage collection and bounds checking enabled by default (of course, optionally turned off if you really must have the performance).
Langages should have very clean and consitent APIs. Having few orthagonal types helps make a language clean Languages should merge character arrays and strings (arguably the Algol languages have had this for a while). If a language wants to be able to have immutable strings, it should provide a way to declair an immutable variant of each fundamental type. (This is actually very useful in writing less buggy code.) Languages should strictly define the size of fundametal numeric types. (I really like Python, but it seems a huge mistake that an integer is "at least 32-bits". Allowig variations in size of fundametal numeric types adds cross-platform bugs. If I wrote a language, the types would look like "int32" "int64" "float32", "float64", "complex32" and "complex64". We got rid of 9- and 12-bit bytes. We should further get rid of these headaches.) Having worked with lots of engineers and scientists, I would love to see complex numbers as basic numeric types that all of the normal operators work on. Wrapping two doubles in an object adds a function call overhead for each numeric operation. Performance with complex numers (and numbers in general) is one big reason a lot of the code I see is written in F
Is "gaol" the correct British spelling of the American "jail"?
If you like XEmacs, you'll also need X11 and an official OS.
BTW, where is ctrl on a German keyboard? I was in Germany a couple of weeks ago composing email in an internet cafe and got done composing the email only to discover I couldn't C-x C-s, C-x C-c.
Uhh... so does Google need to implement a way to block access to its service to people that are habitual copyright infringers? I'd love to see someone get the (MP/RI)AA banned from all major search engines by showing habitual copyright infringement from behind their NAT boxes. (In any good sized organization, you'll find infringement.)
I can see a GUI packge/ports manager, but you have all of about 8 options in the installer. A GUI instller would be larger and more error prone. I've used GRUB to boot OpenBSD and it works fine, although it's a bit much for just a bootloader.
Caller: "Umm, I accidently emailed my plot to kill my wife to a co-worker instead of my lover. Could you please delete it?" Of course, this example assumes you believe murder is amoral and only sheds light on the previous case if you also believe adultery is amoral.
A known overwrite history helps in interpreting residual data. The usual way people in the know suggest overwriting the HD is to use /dev/random to generate an encrypion key, then create an encrypted block device (say, by using an encryptd loopback device) using that key, then writing encrypted zeros to the disk. Wash, rinse, repeat.
Note that overwriting the entire disk several times is a big stress on the drive. I've killed two hard drives during secure deletion of content. I suspect it was a heating problem. Cheap OEM HDs aren't designed to undergo contant writes for hours on end several years after manufacture. Then again, maybe I just have bad luck.
Random data should give you the worst compression ratio, but not necessarily speed. bzip2 starts out by using a poor compression agorithm (RLE) before the BWT becuse the worst case for the bwt is all of the bytes being the same. The BWT actually runs very fast with random inputs compared to all zeros, for instance.
It's probably there to distinguish platonic coed residences from romantic unmarried cohabitation. It would appear to be legal to live with someone of the oposite sex as long as there is no naked fun involved.
I have two female apartment mates. They sleep in a seperate room from me. I have never been romantical involved with either of them by any stretch of the imagination (well, unless you count my ex GF's imagination). If I was in Michigan and that clause wasn't in there, that would be yet another law hanging over my head.
However, the grandparent poter should RTFA. This is perpetual motion, but not a perpetual motion machine because it cannot be used to do work indefinately. The specific case of atoms is discussed in TFA.
I'm not sure which directories GNUnet links to directly. GNUnet certainly doesn't censor any content, so you can get the same stuff through that client. My point was simply that anyone claiming to support free speech shouldn't throw out the entire official freenet client because the directory they link to links to everything under the sun, including kiddie porn. You could probably Google for kiddie porn and find some, but very few people boycot Mozilla becuase it uses Google as its default search engine.
The Reuters reporters didn't say there aren't burning oil wells. They say they can't see any. Maybe the U.S. is lying, but realize that the reporters aren't contradicting the official U.S. story. If the reporters were roaming around the oil fields looking for the handful that are said to be burning, that would be a different story.
If you put a heat engine on the CPU, you reduce energy transfer versus a heatsink/heatpipe. You coul recover a small percentage of the power, but it's really not worth it.