I know this may seem like flaimbait, but I cant stand it when people post armchair assertions as fact from a quick skim of a site.
It's an all too common phenomenon - a flashy web page with zero technical details, hyping a product that will never see the light of day.
If you say they've made a prototype, I beleive you, but don't blame me for my "armchair assertion". Blame Danger's marketing dept. And the pic most certainly *is* fake/altered, even if the product is real. No way that image on the LCD was photographed.
Anyway, more power to these guys if the product is for real. It sounds like a great gadget, but I can't get excited over a flash animation!
It would have been nice if Redhat had given the AUTHORS of wu-ftpd notice that they were going to post this! This wreaks. I'm browsing around www.wu-ftpd.org and ftp://ftp.wu-ftpd.ord and I can't find any mention of this.
Crap - where am I supposed to get the fix in a non-Redhat-proprietary, non-rpm, source code form? All that's listed in the advisory are a bunch of links to binary downloads at updates.redhat.com, the bastards.
HAHAHAHA trust me inertial guidence / positioning can be made VERY accurate with nearly NO drift.
Clearly you don't have a clue and you're just trolling, but it's worth clarifying the drift problem:
What good is "nearly" no drift? If there's any drift at all, then it means you *have* to have an occasion external reference. If you're talking about a 20 minute missile flight then you're okay, but it doesn't work if you want to track your position for the course of a longer trip.
There is always some noise in your samples, and there's always data lost between sampling intervals. You're integrating twice and then adding up a whole bunch of deltas, each with some error. Over time, your calculated position WILL ALWAYS drift further and further from your actual position. That's why inertial navigation is seldom preferred when GPS or Loran is available.
lets just say it is more accurate than military grade GPS.
Bullsh*t - under what circumstances? Where do you think you're going to get the initial position to program the inertial guidance system?
How would an accelerometer distinguish between rotation, acceleration, deceleration, etc.?
One accelerometer can't. You need accelerometers on all three axes to detect which direction you're moving, and you need gyros for pitch/yaw/roll. I beleive the inexpensive solid state gyros are just two parallel accelerometers (A and B) with your point of reference (X) in the middle.
If you rotate around X, you'll measure downward acceleration on A and upward acceleration on B.
The real problem is not measuring acceleration (or rotation), the problem is converting this to speed (integral of acceleration). Accelerometers are great for measuring speed over a short period of time. For example, with just one accelerometer you can very accurately measure a car's 0-60 time and 1/4 mile speed. However, without an occasional speed or position sample, your calculated speed will always be drifting.
You clipped off the rest of my sentence and took it out of context. What I said re SPDIF was:
It would be nice, but you have to understand that it's not worth the extra $20 to the 90% of our customers who will never use it.
Everybody appreciates a high quality display, remote, and UI. Almost nobody would be able to tell the difference between an MP3 played through the player's DAC vs.the one in their receiver.
I am acknowledging, however, that there is a significant portion of the market that would use the digital output. When you're designing cost-sensitive hardware, you have to make calculated decisions, taking into account what your customers want, what they're willing to pay, mechanical considerations, whether it's feasible to make it an add-on card, etc. Trust me, I researched it very carefully.
BTW have you ever done a blind test between differenct 44KHz/16-bit DACs? I have reasonably good ears - I can usually tell the difference between CDs and 384K mp3s, but I've never been able to tell the difference between a $10 and a $100 DAC using the same amp/speakers and the same digital source.
In fact the website says "The SliMP3 is not yet ready for sale. If you would like to receive an e-mail when our first units become available, please submit the form below." so I guess right now it isn't available at all.
FYI, we've scaled up production and we expect our first batch of professionally manufactured players to be available by the end of December.
Plus it's about $70 more expensive even though it contains less hardware (price of hand assembly).
It's more expensive because it's better, not because we're making them in smaller qty. We've invested a considerable amount of R&D into custom software and hardware, and most of it is open and hackable - this isn't just another embedded PC. Also we're using a high quality 40x2 Vacuum fluorescent display instead of a backlit LCD. Most folks think these features are worth the extra $$.
I think both these devices should be updated to include a TOSlink/coaxial output (preferably both).
It would be nice, but you have to understand that it's not worth the extra $20 to the 90% of our customers who will never use it. Also, the other 10% will probably realize that the CD player DAC is going to sound just as good with MP3 as the one in their receiver.
I'd see one or two packets per day that passed Ethernet CRC but failed TCP/IP checksums, even from the local net
Any Ethernet frame, valid or not, will have a correct CRC, unless there is a problem on your local LAN. Also, your router wouldn't look at TCP or TCP checksums, but it certainly shouldn't pass anything with an incorrect IP checksum.
It sounds like you may have been attributing some of these malformed packets to faulty TCP/IP stacks on the other end, when the problem was actually your LAN or gateway. Were you using experimental layer 2/3 equipment?
I didn't have a chance to get to the other link before farces.com went down, but here's the first page (edited to pass junk filter):
A few months ago, I published an article outlining my opinion and experience with spammers in general and one in particular. That article, Fun with spammers, has drawn the attention of the subject spammer?s lawyer, and I am being threatened with legal action.
I am publishing both the demand and my response without comment. Your comments are most welcome.
Today I received the following letter on lawyer letterhead:
Gary K. Kahn
-address-
November 12, 2001
Michael Fraase
-address-
RE: Dispute Involving E-Core Technologies, Inc.
Dear Mr. Fraase:
This office represents Jim Hobuss of Portland, Oregon. Mr. Hobuss has called my attention to information you have placed on the internet regarding Mr. Hobuss. Specifically, you have defamed Mr. Hobuss in your posting and it is clear you are attempting to interfere with his business.
On behalf of Mr. Hobuss, demand is hereby made upon you to remove any reference to Mr. Hobuss from your posting. If you fail to do so within ten (10) days, my client will consider all appropriate legal recourse against you.
Sincerely, REEVES, KAHN & HENNESSY (signed)
Gary K. Kahn
To which I responded on my business letterhead:
ARTS & FARCES LLC
-address-
16 November 2001
Gary K. Kahn
--address-
Dear Mr. Kahn,
I received your letter concerning Mr. Hobuss? claims of defamation in information posted on the ARTS & FARCES internet website. I believe the article in question can be found at:
http://www.farces.com/farces/999462920/
under the title ?Fun with spammers.?
The piece accurately reflects my email experience with Mr. Hobuss and my opinion of that experience. I stand by the article and have no intention of removing it from publication. Nor do I intend to remove any reference to Mr. Hobuss in the piece.
In fact, I expect to publish a follow-up piece including the text of your letter and this response.
Your client?s account with this firm is now seriously past due, and I?d like to know what his intention is with regard to my unpaid invoice(s).
You forgot to mention the inverse relationship between the value of data and the cost of serving it. What I mean is, if I were to assign a "usefulness" factor to the things I download, in terms of "points", it would be
I believe this is due to the orientation of the wavelan card. It sits horizontally, so the antenna is pointing straight up.
The base station comes with a bracket for wall-mounting. For the best range, I think you're supposed to put it on the wall, pointing in the general direction of the clients.
I, too, have found the range of my Airport to be about 100'. That's with the base station indoors and my powerbook outdoors, and the base station sitting horizontally, on it's feet.
One thing that's nice about the Airport is that unlike the cheaper base stations, it uses a an Orinoco Wavelan card which can support an external antenna. So if you want to add a higher gain patch antenna or a parabolic dish for long distance links, all you have to do is drill a hole in the cover to get to the connector.
If you like this one...
on
80 Gig MP3 Player
·
· Score: 3, Informative
This site is slashdotted, so I can't really see what they've got. I did find in google's cache a copy of the image on that page though.
It looks like this player does not have much buffering to speak of. So it wouldn't be very useful for a portable player. This one looks like a commendable effort, but I'd recommend PRJC.com if you're doing a portable player - large SDRAM means you can spin down the drive. Plus it's open source!
If we learned anything last year, it's that you can't make money giving stuff away for free (duh). But "freeness" barely scratches the surface of what open source is all about.
I remember that the user's manual for my first Apple computer came with a huge fold-out schematic of the entire motherboard. The design wasn't free, but it was open insofar as I didn't have to reverse engineer it just to hack on it. Do you think any more than a tiny handful of Apple's customers had the faintest clue what to do with the schematic? Or course not.
However, when you open up your product, even if it's not to the full extent of GPLing everything, you're inviting hackers and hobbyists to develop all sorts of software and peripherals... AND THIS HELPS YOUR BUSINESS ENORMOUSLY!!! Open source developers sometimes do it because they want to give something to the world. Other times, we do it because we just want to improve the stuff we own. We share our changes because it doesn't cost us anthing to do it.
It's not too hard to think of business models where both your customers *and* your business can benefit from open source. Make a software product and open source the hardware, or <plug>make a hardware product and open source the software</plug>. You could even make a software product and open just part of it. Neither the open source community nor your customers will demand that you give away the farm for nothing.
Slashdot already seems to have a queue system for releasing stories at regular intervals - you could just email the owner of the site when the story gets added to the queue.
This would give them time to go through and reduce the size of their images, call up their provider and order more bandwidth, etc. On the other hand, it would undermine slashdot's sterling reputation for journalistic integrity - you would end up with webmasters making changes to *content* of their site in advance.
There are two chips which are very common for MPEG decoding in portable electronics - the MAS3507D and the STA013. Both of these chips are essentially "black boxes" - MPEG in, PCM out. Their DSPs have just enough horsepower to do MPEG decoding, and the firmware is all in ROM. Ogg decoding, as many have already pointed out, needs considerable amount of additonal CPU cycles and RAM as compared to MPEG. Ogg just wasn't designed for embedded systems. Right now the only remotely viable solution for OGG decoding in a portable device would be to go with something like an ARM system-on-chip. Would you pay $250 for a portable player that supported OGG when you can get an equivalent MP3 player for $150? I didn't think so.
I just don't understand the objection to MP3... it's a decent format, well worth the $2/unit royalty for the decoder chips. Maybe MPEG doesn't compress as well as Ogg, but I would consider this an even trade for the less expensive decoding.
I agree - even a SDRAM controller right on the PCI bus can't be as fast as the system's main memory.
Linux, FreeBSD, and MacOSX (I dunno about Windows) all have excellent VM and file system caches (sometimes they're tightly integrated). If you have 4GB of RAM in your system, and your running processes have 64MB resident, then it's like having a 3.94GB RAM disk. That is, of course, unless you routinely access more than 3.94GB of files.
This is why having lots of RAM is good, even if your processes don't use much.
It's not prefect - I know that on FreeBSD 4, for example, if you have zillions of small frequently used files in the cache, and then you do a big tar, all those important little files will get pushed out of the cache in favor of the new file, which might only be accessed once. Also, the kernel will swap processes out to make room for file system cache, and there aren't a lot of knobs for tuning all of this. EG I don't think you tell the kernel "keep *all* my processes resident, even if they're idle... no really, I *do* have enough RAM!"
Anyway I just don't see any use for standalone RAM disks. There are very few real-world applications that need *deterministic* 1ms seek times. If you rely on the OS you will generally get the best performance.
The need to replicate BBS content was driven only by the cost of calling long distance. BBSes would certainly have been more centralized (and specialized) if long distance had been free back then.
I'm surprised that the Internet has made it this far without any kind of "per hop" pricing... I can buy a leased line in California, and my traffic to Australia costs no more than my traffic going across town. It just doesn't seem like a sustainable model.
So replication of Internet content is driven not so much by cost (yet), but rather by the needs for performance, evasion of law enforcement, and load distribution.
Meanwhile, google is doing a pretty good job of archiving things for posterity. Still it would be great to see a FreeNet-like system actually work long term, and have all the most important content mirrored everywhere, forever.
I think we *are* making progress.
Re:Concatenating strings
on
Apocalypse 3
·
· Score: 1
The problem (esp in Perl, but also Javascript and others) is that the context mostly determines whether a number is interpreted as a string or a real number.
The most obvious problems occur when concatenating numbers, like
$phonenumber = $areacode + $phonenumber;
In Javascript, I think you have to do something like
phonenumber = areacode + '' + $phonenumber
to make it understand that you want concatenation, not addition.
Perl currently makes good use of all the symbols
on the keyboard, even tilde and backtick. I always thought the dot was a very elegant way to represent concatenation. Still, I'd give it up for real perl structs:)
Re:Concatenating strings
on
Apocalypse 3
·
· Score: 1
No, the dot is very useful. You can't get by with just "$a$b"
For appending:
$a.=$b;
For expressions:
print '$'.(int($amount/100)).($amount%100)."\n";
Concatenating strings
on
Apocalypse 3
·
· Score: 4, Insightful
He stresses the importance of good huffman coding, then goes on to change the string concatenation operator "." to a three character sequence " _ "
...instead of:
$a . $b . $c
you'll say:
$a _ $b _ $c
String concatenation is such a commonly used perl feature that it deserves a single character operator. Discriminating between operators by the existence of white space before/after the character is an incredibly ugly kludge. Larry seems to admit it, too: This is to be construed as a feature
At least we don't have to use "+", like in JavaScript!
How hard can it be to guard from bit rot with cheap, conventional silicon?
You could do this with three (or more) identical systems running in parallel. If one of them loses sync with the other, he could halt the system, reload his state from the others (which are still in consesus) and then resume. I know I'm over simplifying this, but we're already using such hardware redundancy schemes on Earth.
Slashdot Mirror
I know this may seem like flaimbait, but I cant stand it when people post armchair assertions as fact from a quick skim of a site.
It's an all too common phenomenon - a flashy web page with zero technical details, hyping a product that will never see the light of day.
If you say they've made a prototype, I beleive you, but don't blame me for my "armchair assertion". Blame Danger's marketing dept. And the pic most certainly *is* fake/altered, even if the product is real. No way that image on the LCD was photographed.
Anyway, more power to these guys if the product is for real. It sounds like a great gadget, but I can't get excited over a flash animation!
$36,000,000.00???????
For a friggin **CONCEPT**?
It would have been nice if Redhat had given the AUTHORS of wu-ftpd notice that they were going to post this! This wreaks. I'm browsing around www.wu-ftpd.org and ftp://ftp.wu-ftpd.ord and I can't find any mention of this.
Crap - where am I supposed to get the fix in a non-Redhat-proprietary, non-rpm, source code form? All that's listed in the advisory are a bunch of links to binary downloads at updates.redhat.com, the bastards.
I'd say RMS is more of a one-legged cat trying to bury turds on a frozen lake....
Damn, I got modded up. I wouldn't have posted that anonymously if I didn't think it was an utterly useless comment.
More beer.
:)
HAHAHAHA trust me inertial guidence / positioning can be made VERY accurate with nearly NO drift.
Clearly you don't have a clue and you're just trolling, but it's worth clarifying the drift problem:
What good is "nearly" no drift? If there's any drift at all, then it means you *have* to have an occasion external reference. If you're talking about a 20 minute missile flight then you're okay, but it doesn't work if you want to track your position for the course of a longer trip.
There is always some noise in your samples, and there's always data lost between sampling intervals. You're integrating twice and then adding up a whole bunch of deltas, each with some error. Over time, your calculated position WILL ALWAYS drift further and further from your actual position. That's why inertial navigation is seldom preferred when GPS or Loran is available.
lets just say it is more accurate than military grade GPS.
Bullsh*t - under what circumstances? Where do you think you're going to get the initial position to program the inertial guidance system?
Here's a good intro to inertial navigation if you're interested.
How would an accelerometer distinguish between rotation, acceleration, deceleration, etc.?
One accelerometer can't. You need accelerometers on all three axes to detect which direction you're moving, and you need gyros for pitch/yaw/roll. I beleive the inexpensive solid state gyros are just two parallel accelerometers (A and B) with your point of reference (X) in the middle.
If you rotate around X, you'll measure downward acceleration on A and upward acceleration on B.
The real problem is not measuring acceleration (or rotation), the problem is converting this to speed (integral of acceleration). Accelerometers are great for measuring speed over a short period of time. For example, with just one accelerometer you can very accurately measure a car's 0-60 time and 1/4 mile speed. However, without an occasional speed or position sample, your calculated speed will always be drifting.
Thanks for the feedback.
You clipped off the rest of my sentence and took it out of context. What I said re SPDIF was:
It would be nice, but you have to understand that it's not worth the extra $20 to the 90% of our customers who will never use it.
Everybody appreciates a high quality display, remote, and UI. Almost nobody would be able to tell the difference between an MP3 played through the player's DAC vs.the one in their receiver.
I am acknowledging, however, that there is a significant portion of the market that would use the digital output. When you're designing cost-sensitive hardware, you have to make calculated decisions, taking into account what your customers want, what they're willing to pay, mechanical considerations, whether it's feasible to make it an add-on card, etc. Trust me, I researched it very carefully.
BTW have you ever done a blind test between differenct 44KHz/16-bit DACs? I have reasonably good ears - I can usually tell the difference between CDs and 384K mp3s, but I've never been able to tell the difference between a $10 and a $100 DAC using the same amp/speakers and the same digital source.
In fact the website says "The SliMP3 is not yet ready for sale. If you would like to receive an e-mail when our first units become available, please submit the form below." so I guess right now it isn't available at all.
FYI, we've scaled up production and we expect our first batch of professionally manufactured players to be available by the end of December.
Plus it's about $70 more expensive even though it contains less hardware (price of hand assembly).
It's more expensive because it's better, not because we're making them in smaller qty. We've invested a considerable amount of R&D into custom software and hardware, and most of it is open and hackable - this isn't just another embedded PC. Also we're using a high quality 40x2 Vacuum fluorescent display instead of a backlit LCD. Most folks think these features are worth the extra $$.
I think both these devices should be updated to include a TOSlink/coaxial output (preferably both).
It would be nice, but you have to understand that it's not worth the extra $20 to the 90% of our customers who will never use it. Also, the other 10% will probably realize that the CD player DAC is going to sound just as good with MP3 as the one in their receiver.
I'd see one or two packets per day that passed Ethernet CRC but failed TCP/IP checksums, even from the local net
Any Ethernet frame, valid or not, will have a correct CRC, unless there is a problem on your local LAN. Also, your router wouldn't look at TCP or TCP checksums, but it certainly shouldn't pass anything with an incorrect IP checksum.
It sounds like you may have been attributing some of these malformed packets to faulty TCP/IP stacks on the other end, when the problem was actually your LAN or gateway. Were you using experimental layer 2/3 equipment?
I didn't have a chance to get to the other link before farces.com went down, but here's the first page (edited to pass junk filter):
A few months ago, I published an article outlining my opinion and experience with spammers in general and one in particular. That article, Fun with spammers, has drawn the attention of the subject spammer?s lawyer, and I am being threatened with legal action.
I am publishing both the demand and my response without comment. Your comments are most welcome.
Today I received the following letter on lawyer letterhead:
Gary K. Kahn
-address-
November 12, 2001
Michael Fraase
-address-
RE: Dispute Involving E-Core Technologies, Inc.
Dear Mr. Fraase:
This office represents Jim Hobuss of Portland, Oregon. Mr. Hobuss has called my attention to information you have placed on the internet regarding Mr. Hobuss. Specifically, you have defamed Mr. Hobuss in your posting and it is clear you are attempting to interfere with his business.
On behalf of Mr. Hobuss, demand is hereby made upon you to remove any reference to Mr. Hobuss from your posting. If you fail to do so within ten (10) days, my client will consider all appropriate legal recourse against you.
Sincerely, REEVES, KAHN & HENNESSY (signed)
Gary K. Kahn
To which I responded on my business letterhead:
ARTS & FARCES LLC
-address-
16 November 2001
Gary K. Kahn
--address-
Dear Mr. Kahn,
I received your letter concerning Mr. Hobuss? claims of defamation in information posted on the ARTS & FARCES internet website. I believe the article in question can be found at:
http://www.farces.com/farces/999462920/
under the title ?Fun with spammers.?
The piece accurately reflects my email experience with Mr. Hobuss and my opinion of that experience. I stand by the article and have no intention of removing it from publication. Nor do I intend to remove any reference to Mr. Hobuss in the piece.
In fact, I expect to publish a follow-up piece including the text of your letter and this response.
Your client?s account with this firm is now seriously past due, and I?d like to know what his intention is with regard to my unpaid invoice(s).
Regards,
(signed)
Michael Fraase
You forgot to mention the inverse relationship between the value of data and the cost of serving it. What I mean is, if I were to assign a "usefulness" factor to the things I download, in terms of "points", it would be
size points cost(KB)/point
Movie trailer 20M 4 5120.00
Lesbo pr0n 1M 1 1024.00
IP phone call 1M 20 51.20
/. article 100K 5 20.00
stock quote 30K 5 6.00
instant message 100B 2 0.05
important email 1K 25 0.04
The "charge-per-bit" system is wonderful - I like paying 1/20,000 as much to receive an important email as I pay to download a movie advertisement!
Bandwidth is *incredibly* cheap, when you think about it, and it's all thanks to pr0n.
Moderate size web page, included embedded objects: 100Kbytes, or 800Kbit
1Mbit bandwidth & shelf space: about $400/mo
Typical average daily throughput for a web site that serves 1Mbit at midday: 0.75 * 1Mbit == 750Kbps
So total pages served in a month:
750*60*60*24*30 / 800 = 2,430,000
At 1 cent per page, you'd gross $24,300 for the month.
Total cost of bandwidth per page:
400 / 2,430,000 = $0.000165
And you thought the dot-coms were out of hand before...
The base station comes with a bracket for wall-mounting. For the best range, I think you're supposed to put it on the wall, pointing in the general direction of the clients.
I, too, have found the range of my Airport to be about 100'. That's with the base station indoors and my powerbook outdoors, and the base station sitting horizontally, on it's feet.
One thing that's nice about the Airport is that unlike the cheaper base stations, it uses a an Orinoco Wavelan card which can support an external antenna. So if you want to add a higher gain patch antenna or a parabolic dish for long distance links, all you have to do is drill a hole in the cover to get to the connector.
Check out pjrc's board
This site is slashdotted, so I can't really see what they've got. I did find in google's cache a copy of the image on that page though.
It looks like this player does not have much buffering to speak of. So it wouldn't be very useful for a portable player. This one looks like a commendable effort, but I'd recommend PRJC.com if you're doing a portable player - large SDRAM means you can spin down the drive. Plus it's open source!
If we learned anything last year, it's that you can't make money giving stuff away for free (duh). But "freeness" barely scratches the surface of what open source is all about.
I remember that the user's manual for my first Apple computer came with a huge fold-out schematic of the entire motherboard. The design wasn't free, but it was open insofar as I didn't have to reverse engineer it just to hack on it. Do you think any more than a tiny handful of Apple's customers had the faintest clue what to do with the schematic? Or course not.
However, when you open up your product, even if it's not to the full extent of GPLing everything, you're inviting hackers and hobbyists to develop all sorts of software and peripherals... AND THIS HELPS YOUR BUSINESS ENORMOUSLY!!! Open source developers sometimes do it because they want to give something to the world. Other times, we do it because we just want to improve the stuff we own. We share our changes because it doesn't cost us anthing to do it.
It's not too hard to think of business models where both your customers *and* your business can benefit from open source. Make a software product and open source the hardware, or <plug>make a hardware product and open source the software</plug>. You could even make a software product and open just part of it. Neither the open source community nor your customers will demand that you give away the farm for nothing.
The /. Paradox: No matter how idiotic/profane your post, you are guaranteed to get modded up if you simply say "mod me down".
Mod me down, motherfuckers.
Slashdot already seems to have a queue system for releasing stories at regular intervals - you could just email the owner of the site when the story gets added to the queue.
This would give them time to go through and reduce the size of their images, call up their provider and order more bandwidth, etc. On the other hand, it would undermine slashdot's sterling reputation for journalistic integrity - you would end up with webmasters making changes to *content* of their site in advance.
There are two chips which are very common for MPEG decoding in portable electronics - the MAS3507D and the STA013. Both of these chips are essentially "black boxes" - MPEG in, PCM out. Their DSPs have just enough horsepower to do MPEG decoding, and the firmware is all in ROM. Ogg decoding, as many have already pointed out, needs considerable amount of additonal CPU cycles and RAM as compared to MPEG. Ogg just wasn't designed for embedded systems. Right now the only remotely viable solution for OGG decoding in a portable device would be to go with something like an ARM system-on-chip. Would you pay $250 for a portable player that supported OGG when you can get an equivalent MP3 player for $150? I didn't think so.
I just don't understand the objection to MP3... it's a decent format, well worth the $2/unit royalty for the decoder chips. Maybe MPEG doesn't compress as well as Ogg, but I would consider this an even trade for the less expensive decoding.
I agree - even a SDRAM controller right on the PCI bus can't be as fast as the system's main memory.
Linux, FreeBSD, and MacOSX (I dunno about Windows) all have excellent VM and file system caches (sometimes they're tightly integrated). If you have 4GB of RAM in your system, and your running processes have 64MB resident, then it's like having a 3.94GB RAM disk. That is, of course, unless you routinely access more than 3.94GB of files.
This is why having lots of RAM is good, even if your processes don't use much.
It's not prefect - I know that on FreeBSD 4, for example, if you have zillions of small frequently used files in the cache, and then you do a big tar, all those important little files will get pushed out of the cache in favor of the new file, which might only be accessed once. Also, the kernel will swap processes out to make room for file system cache, and there aren't a lot of knobs for tuning all of this. EG I don't think you tell the kernel "keep *all* my processes resident, even if they're idle... no really, I *do* have enough RAM!"
Anyway I just don't see any use for standalone RAM disks. There are very few real-world applications that need *deterministic* 1ms seek times. If you rely on the OS you will generally get the best performance.
The need to replicate BBS content was driven only by the cost of calling long distance. BBSes would certainly have been more centralized (and specialized) if long distance had been free back then.
I'm surprised that the Internet has made it this far without any kind of "per hop" pricing... I can buy a leased line in California, and my traffic to Australia costs no more than my traffic going across town. It just doesn't seem like a sustainable model.
So replication of Internet content is driven not so much by cost (yet), but rather by the needs for performance, evasion of law enforcement, and load distribution.
Meanwhile, google is doing a pretty good job of archiving things for posterity. Still it would be great to see a FreeNet-like system actually work long term, and have all the most important content mirrored everywhere, forever.
I think we *are* making progress.
The problem (esp in Perl, but also Javascript and others) is that the context mostly determines whether a number is interpreted as a string or a real number.
:)
The most obvious problems occur when concatenating numbers, like
$phonenumber = $areacode + $phonenumber;
In Javascript, I think you have to do something like
phonenumber = areacode + '' + $phonenumber
to make it understand that you want concatenation, not addition.
Perl currently makes good use of all the symbols
on the keyboard, even tilde and backtick. I always thought the dot was a very elegant way to represent concatenation. Still, I'd give it up for real perl structs
No, the dot is very useful. You can't get by with just "$a$b"
For appending:
$a.=$b;
For expressions:
print '$'.(int($amount/100)).($amount%100)."\n";
He stresses the importance of good huffman coding, then goes on to change the string concatenation operator "." to a three character sequence " _ "
...instead of:
$a . $b . $c
you'll say:
$a _ $b _ $c
String concatenation is such a commonly used perl feature that it deserves a single character operator. Discriminating between operators by the existence of white space before/after the character is an incredibly ugly kludge. Larry seems to admit it, too: This is to be construed as a feature
At least we don't have to use "+", like in JavaScript!
How hard can it be to guard from bit rot with cheap, conventional silicon?
You could do this with three (or more) identical systems running in parallel. If one of them loses sync with the other, he could halt the system, reload his state from the others (which are still in consesus) and then resume. I know I'm over simplifying this, but we're already using such hardware redundancy schemes on Earth.
Err.. never mind I figured it out. The big triangles are actually 4-sided. The small triangles have different angles.