At the trailing edge of the wing, air wants to come back together at the same point where it was split apart by the leading edge. So the air passing over the top of the wing has to go faster to meet up with the air which goes a shorter distance, under the wing. Since the same number of air molecules are spread across a larger distance on the top of the wing, you get less pressure, hence lift.
Then 12345.js would contain a document.write() with the contents of that post. Or are there other ways to do this?
What this gets you is client-side caching of most of the dynamically generated stuff. When you descend a thread or change the display mode, the browser has already cached a separate object for each post, so it only has to fetch new stuff from the server. This would reduce bandwidth, web server, and database load.
The downside to this is that on the first page load, you incur a whole bunch of individual HTTP requests. But I guess you already have a way to serve static pages for the first couple of levels. I think/. readers would be okay with a longer initial page load, if it meant that subsequent pages would come up much faster.
There are just two cases when I ever use paper these days, and I'd love to eliminate them:
1 - Somebody gives me old fashioned bills or credit card receipts on paper.
2 - I want to see something at >72dpi.
It's hard to get excited about e-paper... I want to have no-paper, not more-paper, e- or not.
This technology seems like a giant step backwards from where we're headed with lower cost, larger, and higher-res LCD displays.
Re:First question
on
MenuetOS Debuts
·
· Score: 2, Insightful
The question of "is it practical to code is assembler" is utterly meaningless, without some context. If you're writing firmware for a low cost, mass produced embedded product, your development time/cost is not crititcal, and you plan to sell a million units, then by all means, code *everything* in assembler. Save $2 by using a smaller CPU/RAM/ROM, and that's an extra $2 million you can afford to spend on development.
In this case, the guy was writing an operating system. It fits on a floppy disk. It's really fast. So what, you might say... I have a $1K PC with an 80GB hard drive, what the hell do I care how fast printk() is, or the size of my kernel image.
Now imagine you're developing a router, or a Tivo, or an Internet toaster. You need an OS. Your choices are Linux, running on a $40 ARM or PowerPC chip, or Menuet, running on a $10 i386.
Besides the compelling practical applications for MenuetOS, I'm sure the guy learned one hell of a lot about computer architecture in the process of writing it. It's not just about hack value - coding in ASM is a wonderful learning experience.
TCP can't "broadcast"... it's for bidirectional links. I think what you mean is why don't radio stations broadcast digitally - perhaps with some FEC, perhaps MPEG compressed, so that we can all get perfect CD-quality music over the airwaves in our cars, on our cell phones and PDAs, etc. Of course, this new format would require everyone to replace their 1940's style FM radios, but that's hardly an obstacle here - consumers would love it!
The problem is that the record companies *love* the crappy sound quality of FM radio. Hear a new song you like on radio - go buy the CD if you want to hear it without all the distortion (inherent in analog radio) and "loudness" (deliberately added by the station, as if you don't have a "bass" knob on your radio). It's worked for decades.
Digital audio over radio to the masses may not happen this century, but it has already happened over the 'net. As storage becomes cheaper and more kinds of players hit the market, people will care less and less what's being played on public radio, and there isn't a damn thing the RIAA or the stations can do about it. They're selling ice in an age of refridgerators.
What happens if and when the server crashes? Does the unit remember its past configuration?
Do you mean the SliMP3 server program (it doesn't crash), or the server machine/os? Anyway, no, you don't have to re-enter the IP config if the SliMP3 player is power-cycled. It's stored in flash.
Also, I think there could be security issues in having an "open" device connecting to the server without any authentication...
The server allows you to restrict access by IP address. The SliMP3 player and server are not intended for sharing MP3s with others, but it is designed to let you service many players from a single machine (over the Internet, if you want). The idea is that you can stick a server in the closet with a few gigs of your legally obtained:) mp3s, and then have a few players in different rooms, all playing different streams from that one server.
It only does MP3, since it pumps everything through a dedicated MPEG
decoder. I will be adding support for other formats (OGG, AIFF, etc) by
encoding/transcoding to MP3 (usually 384K) on the fly in the server, but
these will not be supported natively by the player. I'm considering
adding support for raw PCM audio (so any compressed format can be decoded
on the server, and it sends a 1.5Mbps uncompressed stream to the player)
but this will not be available in 1.0.
I considered selling them as kits. The main problems for me would be
shipping and packaging all the individual components, and providing
documentation and support. For the customer, the problem would be the need
for a number of tools (microcontroller programmer, JTAG programmer,
oscilloscope, in-circuit emulator for testing, rework station, etc). The other issue is
that with some of the surface mount components, you only get one shot at
installing it correctly. If you make a mistake, the whole board might be
hosed! So I don't think it would be feasible to sell bare boards.
I probably will sell just assembled boards, without the display, power
supply, and remote, for people who want to build their own case or use a
different kind of display (eg if you were doing a car installation or
something exotic...)
We'll start shipping in about two weeks. I expect our first batch to sell out rather quickly (thanks, Slashdot!) and we'll start taking pre-orders as soon as that happens.
It is certainly possible, but it's not easy. The SliMP3 firmware is, AFAIK, the only modern IP stack to have been entirely hand-coded in assembler. The hardware we're using is a PIC microcontroller, along with a custom chip (prototyped in a Xilinx CPLD) for doing DMA transfer through an SRAM to the MPEG decoder. It's a rather different design than other embedded Internet platforms - we're cranking 10Mbps through system built around a 20Mhz, 8-bit microcontroller. Of course you don't need this kind of throughput for an MPEG *audio* stream...
So I'm sitting here looking at my MRTG graphs and saying WTF - my server's trying to push out 2.5MBps onto my T1. Oops.
Thanks everyone for you interest in the SliMP3. Yes, we *are* building these by hand, at least the first 100, and we plan to ship in about two weeks. No we're not planning to build our next batch this way.
I'll do my best to answer everyone's questions. Again, thanks for the traffic, and sorry my server can't keep up!
Those circular or rectangular cut-outs in the pavement that you see at intersections - it's just a loop of wire to detect if there are cars waiting at the light...
Well, tons of these have been installed in the last two or three years in silicon valley - on the freeways! All up and down 101, 85, and 280, you can find these things installed in pairs, every quarter mile or so, in each lane.
Great for gathering traffic flow information - but I've also heard that these can single out an individual car by make and model, based on a signature of the waveform generated when the car passes over the sensor. This is plausible - does anyone know if it's actually being done?
Slashdot Mirror
Help!
I spent ten minutes staring at, then I loaded it up in photoshop and tried dragging the pieces around... I still don't get it.
heh. Anybody have a screen grab of this scene?
I'm not a physicist, but...
I always understood that air is "cohesive"...
At the trailing edge of the wing, air wants to come back together at the same point where it was split apart by the leading edge. So the air passing over the top of the wing has to go faster to meet up with the air which goes a shorter distance, under the wing. Since the same number of air molecules are spread across a larger distance on the top of the wing, you get less pressure, hence lift.
that's only for reverse (PTR) lookups
I propose a ".ip TLD". (Unless ip is a country?)
Then you get the best of both worlds. Easy-to-remember DNS names, and the uniqueness of an IP address!
127.64.156.23.ip
CmdrTaco,
/. doesn't do this.
/. readers would be okay with a longer initial page load, if it meant that subsequent pages would come up much faster.
I'm sure you've considered doing page assembly on the client, and I'm curious as to why
EG for each dynamic page, you just serve a skeleton containing javascript references to each of the posts. Such as
<script language="javascript" src="posts/12345.js">
Then 12345.js would contain a document.write() with the contents of that post. Or are there other ways to do this?
What this gets you is client-side caching of most of the dynamically generated stuff. When you descend a thread or change the display mode, the browser has already cached a separate object for each post, so it only has to fetch new stuff from the server. This would reduce bandwidth, web server, and database load.
The downside to this is that on the first page load, you incur a whole bunch of individual HTTP requests. But I guess you already have a way to serve static pages for the first couple of levels. I think
About 7 mils
There are just two cases when I ever use paper these days, and I'd love to eliminate them:
1 - Somebody gives me old fashioned bills or credit card receipts on paper.
2 - I want to see something at >72dpi.
It's hard to get excited about e-paper... I want to have no-paper, not more-paper, e- or not.
This technology seems like a giant step backwards from where we're headed with lower cost, larger, and higher-res LCD displays.
The question of "is it practical to code is assembler" is utterly meaningless, without some context. If you're writing firmware for a low cost, mass produced embedded product, your development time/cost is not crititcal, and you plan to sell a million units, then by all means, code *everything* in assembler. Save $2 by using a smaller CPU/RAM/ROM, and that's an extra $2 million you can afford to spend on development.
In this case, the guy was writing an operating system. It fits on a floppy disk. It's really fast. So what, you might say... I have a $1K PC with an 80GB hard drive, what the hell do I care how fast printk() is, or the size of my kernel image.
Now imagine you're developing a router, or a Tivo, or an Internet toaster. You need an OS. Your choices are Linux, running on a $40 ARM or PowerPC chip, or Menuet, running on a $10 i386.
Besides the compelling practical applications for MenuetOS, I'm sure the guy learned one hell of a lot about computer architecture in the process of writing it. It's not just about hack value - coding in ASM is a wonderful learning experience.
Grep simply isn't suitable for interactive searches of gigabytes of data broken up into millions of files.
For ineractively searching gigabytes of files, we have:
find . -exec grep "cum-stained blue dress" {} \; -print | more
% lynx -dump -source http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1112. html | grep TCP
%
Remember, TCP != IP.
Maybe there's something I'm missing here - why would you want to use IP at all for a radio broadcast?
TCP can't "broadcast"... it's for bidirectional links. I think what you mean is why don't radio stations broadcast digitally - perhaps with some FEC, perhaps MPEG compressed, so that we can all get perfect CD-quality music over the airwaves in our cars, on our cell phones and PDAs, etc. Of course, this new format would require everyone to replace their 1940's style FM radios, but that's hardly an obstacle here - consumers would love it!
The problem is that the record companies *love* the crappy sound quality of FM radio. Hear a new song you like on radio - go buy the CD if you want to hear it without all the distortion (inherent in analog radio) and "loudness" (deliberately added by the station, as if you don't have a "bass" knob on your radio). It's worked for decades.
Digital audio over radio to the masses may not happen this century, but it has already happened over the 'net. As storage becomes cheaper and more kinds of players hit the market, people will care less and less what's being played on public radio, and there isn't a damn thing the RIAA or the stations can do about it. They're selling ice in an age of refridgerators.
What happens if and when the server crashes? Does the unit remember its past configuration?
:) mp3s, and then have a few players in different rooms, all playing different streams from that one server.
Do you mean the SliMP3 server program (it doesn't crash), or the server machine/os? Anyway, no, you don't have to re-enter the IP config if the SliMP3 player is power-cycled. It's stored in flash.
Also, I think there could be security issues in having an "open" device connecting to the server without any authentication...
The server allows you to restrict access by IP address. The SliMP3 player and server are not intended for sharing MP3s with others, but it is designed to let you service many players from a single machine (over the Internet, if you want). The idea is that you can stick a server in the closet with a few gigs of your legally obtained
PG&E meter reader: See here - photos & schematics
It only does MP3, since it pumps everything through a dedicated MPEG
decoder. I will be adding support for other formats (OGG, AIFF, etc) by
encoding/transcoding to MP3 (usually 384K) on the fly in the server, but
these will not be supported natively by the player. I'm considering
adding support for raw PCM audio (so any compressed format can be decoded
on the server, and it sends a 1.5Mbps uncompressed stream to the player)
but this will not be available in 1.0.
I considered selling them as kits. The main problems for me would be
shipping and packaging all the individual components, and providing
documentation and support. For the customer, the problem would be the need
for a number of tools (microcontroller programmer, JTAG programmer,
oscilloscope, in-circuit emulator for testing, rework station, etc). The other issue is
that with some of the surface mount components, you only get one shot at
installing it correctly. If you make a mistake, the whole board might be
hosed! So I don't think it would be feasible to sell bare boards.
I probably will sell just assembled boards, without the display, power
supply, and remote, for people who want to build their own case or use a
different kind of display (eg if you were doing a car installation or
something exotic...)
It's rosin flux.
It would have supported OGG, had there been a low-cost chip for Ogg decoding (like the STA013 and MAS3507D for MP3).
We'll start shipping in about two weeks. I expect our first batch to sell out rather quickly (thanks, Slashdot!) and we'll start taking pre-orders as soon as that happens.
Our first 100 hand-made units are going to sell for $275.
It is certainly possible, but it's not easy. The SliMP3 firmware is, AFAIK, the only modern IP stack to have been entirely hand-coded in assembler. The hardware we're using is a PIC microcontroller, along with a custom chip (prototyped in a Xilinx CPLD) for doing DMA transfer through an SRAM to the MPEG decoder. It's a rather different design than other embedded Internet platforms - we're cranking 10Mbps through system built around a 20Mhz, 8-bit microcontroller. Of course you don't need this kind of throughput for an MPEG *audio* stream...
So I'm sitting here looking at my MRTG graphs and saying WTF - my server's trying to push out 2.5MBps onto my T1. Oops.
Thanks everyone for you interest in the SliMP3. Yes, we *are* building these by hand, at least the first 100, and we plan to ship in about two weeks. No we're not planning to build our next batch this way.
I'll do my best to answer everyone's questions. Again, thanks for the traffic, and sorry my server can't keep up!
Sean Adams
Slim Devices, Inc.
--the simpsons
BS. You can write anything in perl.
---
Well, tons of these have been installed in the last two or three years in silicon valley - on the freeways! All up and down 101, 85, and 280, you can find these things installed in pairs, every quarter mile or so, in each lane.
Great for gathering traffic flow information - but I've also heard that these can single out an individual car by make and model, based on a signature of the waveform generated when the car passes over the sensor. This is plausible - does anyone know if it's actually being done?
---