I wonder how this differs from the dataflow architectures of the early 90s?
Re:It would be a great first language
on
Beginning Ruby
·
· Score: 1
Agreed. Ruby lets you learn in that progression, BTW. Everything is an object, but you don't need to know the details of that day one, at least for simple types like you're describing.
Re:Enlighten me
on
Beginning Ruby
·
· Score: 4, Informative
Hi
First, Ruby != Rails. Ruby is the programming language. Rails (or Ruby on Rails) is the web development framework. Ruby has been around a lot longer than Rails, but has certainly had it's popularity boosted by the buzz surrounding Rails.
Second, I'd disagree that system performance is the biggest factor is selecting a web framework. Rails out of the box will support the load more most websites. There are many things that you can do to tune performance once you start getting enough page views for it to matter: caching pages, selectively replacing ActiveRecord's queries with raw SQL, etc. There are also people starting to focus on rails performance both from a developer's standpoint (e.g., the Rails Express Blog) and from the hosting standpoint (e.g., Engine Yard).
To me, the first and foremost goal of building a website is to get the functionality there quick in order to attract users. Once you've got that, and have rapidly been able to iterate to what the users want to see, then you can start worrying about performance. And, if your site really makes it big, you are going to have to do custom tuning work no matter what framework you've chosen.
Personally, I've found Rails to be a wonderfully productive framework to use for web development
It would be a great first language
on
Beginning Ruby
·
· Score: 4, Insightful
In my opinion, Ruby would make a great first language.
Many computer science departments, including MIT, use Scheme as the language for their introductory computer science course. It's a wonderful language and helps the students learn a lot of key concepts that are important for formal computer science.
Scheme, though, is a little hard to use for real-world work. Ruby, on the other hand, is a great real-world language that has many of the features that I miss from Scheme: closures, lambda expresions, etc.
I haven't read this book, so I can't recommend it, but I can heartily recommend Ruby as a language that would be great to learn to program in. It'll let you focus on the key concepts rather than the tedium of implementing them in lower level languages.
The cable that is tethering it to the ground will be a hazard to aviation and all altitudes below the generator. Not only would the cable be very hard to see, but, unlike power cables and guy wires for antennas, it would also be hard to chart, since I imagine that the generator will move around quite a bit as the jetstream fluctuates.
Re:The days of one-off systems is pretty much dead
on
SGI Arises From the Ashes
·
· Score: 5, Interesting
MIPS processors may be pretty much dead for desktop machines and workstations, but they are very much alive and kicking in the embedded space. For example, take a look at the XLR processor from RMI. This is not your father's MIPS R4000.
I'm afraid we come back to something that marketers have been struggling with for a really long time--the best way to succeed is to have a really great product.
There's a new category of jet aircraft that is all the rage these days: Very Light Jets (VLJs). They are supposed to be cheaper to operate than the current fleet of business jets. AOPA has a good write up of the ones that are the buzz at Oshkosh this year.
The theory is that this new class of jet will be what is needed to enable relatively economical air taxi services that fly from point to point (and likely from smaller airports) rather than flowing your through the current hub-based carriers
There's an interesting project called Place Lab that is building a database of, among other things, cell tower ID to physical location mappings. Their goal is to allow you to "[provide] low-cost, easy-to-use device positioning for location-enhanced computing applications."
Now, they don't have all the data that these guys have, since they just sample the tower that your phone currently happens to be talking to, so you may not be able to get accurate short-term speed readings, but I bet a lot of you could think of fun things to do with it!
Disclaimer: I'm not in any way associated with Place Lab, but I'm considering using it for some LBS experiments and would love to see as many people contributing to their database as possible.:)
OK, thanks to someone else for digging up the real paper. It's actually quite interesting how they do it, and it makes sense. I encourage anyone who is interested to just avoid the article that was posted and read the paper instead. Much more intellectually satisfying...
I just get worked up by how much the press tries to fear monger these days and, given the increbile lack of detail there, assumed it was overblown. After reading the real paper, I have to admit that I was wrong.
yeah, I read the fine article, too. They also had this to say: To intercept this data, a spy would need to use a packet sniffer to intercept a connection from the target computer. This would require that the attacker have access to a network somewhere between the victim and the victim's destination - not a trivial goal, but probably easier than attaching the JitterBug in the first place.
Note that transmitting data between UPenn and Singapore does not mean that the jitter transmission was robust betwen the two points. It just means that they had an observer somewhere (probably as close to the tapped computer as possible) in there that could watch the traffic from the tapped computer and report back to the remote site.
My real issue with the article is that it's so fluffy and fear mongering that it's pretty much useless. The research may be good, but the article certainly doesn't do anything to show that. I'll have to see if I can dig up any refereed publications from these guys and take a closer look.
OK, so they can make a device that adds jitter to the time it takes from when I hit a key to when the computer knows I hit it. Great. Kudos to them for there nice bit of hackery.
But, how exactly does that transmit any information to the outside world? In order to read information out of my delayed key strokes, you'd have to know the cadence that I'd normally be typing at and then measure the deltas to get the bits. Sorry folks, but my typing rate just isn't that consistent.
No, no, that's just an example, you say. The real trick is to embed this in the TCP/IP stack and add jitter to the outgoing packets. Again, nice try, but it's not going to work in the real world. All sorts of things both inside the computer (e.g., page swaps and single-threaded paths in the kernel) and outside of it (e.g. TCP congestion control and Ethernet exponential backoff for collision control) are going to have an effect on the timing of when packets leave the computer.
Interesting in an academice lab, perhaps, but for the real world, schmeh.
Sounds like it would make a great coating for sunglasses, too.
And, if it makes fingerprints stick less, then that'd be an added bonus. I wonder whether the ink-resisitant properties have any effect on oily or gummy buildups.
Following recent seismic activity in California and the threatened eruption of Mount St. Helens in Washington State. Forum takes a look at scientific advancements in the study of earthquakes and volcanoes.
Host: Michael Krasny
Guests:
Dr. Donald Turcotte, professor of geology at UC Davis
Dr. Manuel Nathenson, scientist in charge of the Volcano Hazards Team at US Geological Survey in Menlo Park
Dr. Roland Burgmann, associate professor at Berkeley Seismological Lab at UC Berkeley
Dr. Susan Hough, seismologist at US Geological Survey in Pasadena and author of "Earth Shaking Science: What We Know and Don't Know"
Well, the NASCAR analogy only holds so far. Those cars are highly regulated by specifications of what is "legal" car to race in the league. Some of those specifications are designed to keep a fair playing field; some are designed to keep the drivers safe.
After Dale Sr. died, didn't they start requiring HANS systems to help prevent fatal whiplash? I know they at least talked about it. But, I don't really follow NASCAR that much.
Now, think about the X-prize. There is no standardization on the vehicles that will be competing. That's the whole point. But, if you get a few accidents, there will start to be regulations whether from insurance companies or government. Since you can't really make a one-size-fits-all safety regulation, then you'll either stifle design (i.e. everyone starts to make the same thing because there's only one way to meet the safety requirements) or you'll end up with some designs that are more unsafe because the required safety measure is not appropriate for their design.
Does anyone else think that this is a high-profile accident waiting to happen? A lot of the events mentioned there are about pushing the evelope in terms of speed or capacity. Once enough teams start participating, I'm wondering whether some will sacrifice their safety margin in an attempt to one-up the competition.
The last thing we need is a catastrophic accident that causes a knee-jerk overregulation response from congress.
Does anyone know how this differs from the insect-like robots (like Hannibal
and Attilla) developed by Rod Brooks' group in the MIT AI Lab?
It's been a while since I took his class, but I remember that they
found that remarkably simple distributed control systems could be used
to generate adaptive legged locomation patterns without requiring
complex centralized control.
The caches don't have to be perfectly synced. They just have to snoop each others transactions so that sharing can be arbitrated as necessary.
So, if you have an application in which there is very little or no sharing across the processors, then there is little or no "syncing" involved. In that case, the dual-cache design probably wins over the shared cache in terms of design complexity and perhaps latency to access the cache, depending on how it's done.
Also, separate caches that mantain coherency with each other will scale better to more processor cores than a single shared cache will.
Actually, it's already been done for homebrewers. Beer, Beer, and More Beer sells a nifty conical fermenter that has a chiller as an option. Check it out here.
Personally, I use a lower-tech approach and still have good results.
Your solution causes anyone using multiple pipes to transmit at a higher speed to be stopped short and forced through one incoming interface, even though you might have actually been able to handle the traffic.
Actually, that's not necessarily true. Juniper routers, at least, support a feature called reverse path-forwarding checking that determines whether the source IP is reachable via the interface on which the packet arrived.
If there are multiple interfaces that can reach that address, no problem.
I have to say that if a market didn't exist for embedded linux, why would they feel compelled to say anything about it?
Actually, he said that the marked for embedded Linux tools doesn't exist. On that point, he may be right. gcc + gdb do just fine for most people.
BTW, Green Hills may make an RTOS, but they're primarily known for their tools. They make compilers and a development environment targeted towards embedded systems.
This is probably just my ignorance, but I'm surprised that that wood is actually usable after it has been submereged for so long. Doesn't it rot or become otherwise compromised? Or, is that a slow enough process that there's still plenty of good wood inside the logs?
Slashdot Mirror
My vote for best introduction-to-programming book goes to Structure and Interpretation of Computer Programs (a.k.a. The Wizard Book) by Hal Abelson, Jerry Sussman, and Julie Sussman.
Hmm. Interesting.
I wonder how this differs from the dataflow architectures of the early 90s?
Agreed. Ruby lets you learn in that progression, BTW. Everything is an object, but you don't need to know the details of that day one, at least for simple types like you're describing.
Hi
First, Ruby != Rails. Ruby is the programming language. Rails (or Ruby on Rails) is the web development framework. Ruby has been around a lot longer than Rails, but has certainly had it's popularity boosted by the buzz surrounding Rails.
Second, I'd disagree that system performance is the biggest factor is selecting a web framework. Rails out of the box will support the load more most websites. There are many things that you can do to tune performance once you start getting enough page views for it to matter: caching pages, selectively replacing ActiveRecord's queries with raw SQL, etc. There are also people starting to focus on rails performance both from a developer's standpoint (e.g., the Rails Express Blog) and from the hosting standpoint (e.g., Engine Yard).
To me, the first and foremost goal of building a website is to get the functionality there quick in order to attract users. Once you've got that, and have rapidly been able to iterate to what the users want to see, then you can start worrying about performance. And, if your site really makes it big, you are going to have to do custom tuning work no matter what framework you've chosen.
Personally, I've found Rails to be a wonderfully productive framework to use for web development
Many computer science departments, including MIT, use Scheme as the language for their introductory computer science course. It's a wonderful language and helps the students learn a lot of key concepts that are important for formal computer science.
Scheme, though, is a little hard to use for real-world work. Ruby, on the other hand, is a great real-world language that has many of the features that I miss from Scheme: closures, lambda expresions, etc.
I haven't read this book, so I can't recommend it, but I can heartily recommend Ruby as a language that would be great to learn to program in. It'll let you focus on the key concepts rather than the tedium of implementing them in lower level languages.
Go for it!
The cable that is tethering it to the ground will be a hazard to aviation and all altitudes below the generator. Not only would the cable be very hard to see, but, unlike power cables and guy wires for antennas, it would also be hard to chart, since I imagine that the generator will move around quite a bit as the jetstream fluctuates.
MIPS processors may be pretty much dead for desktop machines and workstations, but they are very much alive and kicking in the embedded space. For example, take a look at the XLR processor from RMI. This is not your father's MIPS R4000.
From marketing dude Seth Godin's Blog:
The theory is that this new class of jet will be what is needed to enable relatively economical air taxi services that fly from point to point (and likely from smaller airports) rather than flowing your through the current hub-based carriers
This morning as I was reading the news about this, and this insightful blog post, I started wondering whether this sort of overreaction is just the thing to give the fledgling air taxi industry a kickstart.
There's an interesting project called Place Lab that is building a database of, among other things, cell tower ID to physical location mappings. Their goal is to allow you to "[provide] low-cost, easy-to-use device positioning for location-enhanced computing applications."
Now, they don't have all the data that these guys have, since they just sample the tower that your phone currently happens to be talking to, so you may not be able to get accurate short-term speed readings, but I bet a lot of you could think of fun things to do with it!
Disclaimer: I'm not in any way associated with Place Lab, but I'm considering using it for some LBS experiments and would love to see as many people contributing to their database as possible. :)
OK, thanks to someone else for digging up the real paper. It's actually quite interesting how they do it, and it makes sense. I encourage anyone who is interested to just avoid the article that was posted and read the paper instead. Much more intellectually satisfying...
I just get worked up by how much the press tries to fear monger these days and, given the increbile lack of detail there, assumed it was overblown. After reading the real paper, I have to admit that I was wrong.
yeah, I read the fine article, too. They also had this to say: To intercept this data, a spy would need to use a packet sniffer to intercept a connection from the target computer. This would require that the attacker have access to a network somewhere between the victim and the victim's destination - not a trivial goal, but probably easier than attaching the JitterBug in the first place.
Note that transmitting data between UPenn and Singapore does not mean that the jitter transmission was robust betwen the two points. It just means that they had an observer somewhere (probably as close to the tapped computer as possible) in there that could watch the traffic from the tapped computer and report back to the remote site.
My real issue with the article is that it's so fluffy and fear mongering that it's pretty much useless. The research may be good, but the article certainly doesn't do anything to show that. I'll have to see if I can dig up any refereed publications from these guys and take a closer look.
OK, so they can make a device that adds jitter to the time it takes from when I hit a key to when the computer knows I hit it. Great. Kudos to them for there nice bit of hackery. But, how exactly does that transmit any information to the outside world? In order to read information out of my delayed key strokes, you'd have to know the cadence that I'd normally be typing at and then measure the deltas to get the bits. Sorry folks, but my typing rate just isn't that consistent. No, no, that's just an example, you say. The real trick is to embed this in the TCP/IP stack and add jitter to the outgoing packets. Again, nice try, but it's not going to work in the real world. All sorts of things both inside the computer (e.g., page swaps and single-threaded paths in the kernel) and outside of it (e.g. TCP congestion control and Ethernet exponential backoff for collision control) are going to have an effect on the timing of when packets leave the computer. Interesting in an academice lab, perhaps, but for the real world, schmeh.
And, if it makes fingerprints stick less, then that'd be an added bonus. I wonder whether the ink-resisitant properties have any effect on oily or gummy buildups.
Anyone care to speculate?
Check out the archived version here
From the blurb:
Following recent seismic activity in California and the threatened eruption of Mount St. Helens in Washington State. Forum takes a look at scientific advancements in the study of earthquakes and volcanoes.
Host: Michael Krasny
Guests:
After Dale Sr. died, didn't they start requiring HANS systems to help prevent fatal whiplash? I know they at least talked about it. But, I don't really follow NASCAR that much.
Now, think about the X-prize. There is no standardization on the vehicles that will be competing. That's the whole point. But, if you get a few accidents, there will start to be regulations whether from insurance companies or government. Since you can't really make a one-size-fits-all safety regulation, then you'll either stifle design (i.e. everyone starts to make the same thing because there's only one way to meet the safety requirements) or you'll end up with some designs that are more unsafe because the required safety measure is not appropriate for their design.
The last thing we need is a catastrophic accident that causes a knee-jerk overregulation response from congress.
Does anyone know how this differs from the insect-like robots (like Hannibal and Attilla) developed by Rod Brooks' group in the MIT AI Lab? It's been a while since I took his class, but I remember that they found that remarkably simple distributed control systems could be used to generate adaptive legged locomation patterns without requiring complex centralized control.
So, if you have an application in which there is very little or no sharing across the processors, then there is little or no "syncing" involved. In that case, the dual-cache design probably wins over the shared cache in terms of design complexity and perhaps latency to access the cache, depending on how it's done.
Also, separate caches that mantain coherency with each other will scale better to more processor cores than a single shared cache will.
Personally, I use a lower-tech approach and still have good results.
Actually, that's not necessarily true. Juniper routers, at least, support a feature called reverse path-forwarding checking that determines whether the source IP is reachable via the interface on which the packet arrived.
If there are multiple interfaces that can reach that address, no problem.
There is a new Internet draft addressing this issue.
Actually, he said that the marked for embedded Linux tools doesn't exist. On that point, he may be right. gcc + gdb do just fine for most people.
BTW, Green Hills may make an RTOS, but they're primarily known for their tools. They make compilers and a development environment targeted towards embedded systems.
M-x rot13-other-window
This is probably just my ignorance, but I'm surprised that that wood is actually usable after it has been submereged for so long. Doesn't it rot or become otherwise compromised? Or, is that a slow enough process that there's still plenty of good wood inside the logs?