> When will candidates who are actually qualified to represent science... be the representatives of science with regard to political decision-making?
You know that Steven Chu is secretary of energy, right? And that the department of energy has a Basic Energy Sciences division which gets a lot of federal science money?
And wasn't there a slashdot story about a physicist-turned-congressman lately?
I mean, yes, I'd like it if it happened more often, and I'm not defending Lamar Smith's qualifications, but it's childish and petty to pretend that it _never_ happens.
An "x86 app" is an app that someone has compiled for x86 and only given you the binary.
Open-source apps are not generally architecture specific. If you have source code and development tools, you can build it on whatever you like, and ARM is pretty mature in this regard. Several Linux distros have ARM ports already, including Debian and Arch, and probably Fedora, and there's a FreeBSD ARM project, also, if you're allergic to the GPL.
And there is Android, for which the OS is natively ARM, even if the app-land is Java.
This ability to mix and match software and hardware in ways not anticipated by the creators of the software or the hardware is exactly why open source is awesome.
Conjecture on my part, but when you pay for an account, you give them some information, so that they can get their money. To a non-infringing free downloader, the cap is an inconvenience, and some fraction of them will be willing to pay to make it go away. To a copyright-infringing free downloader, paying to remove the cap requires them to identify, and possibly incriminate, themselves, so it's more of an obstacle.
This explanation is incomplete, of course, since presumably the uploader is also on the hook for copyright violation, and you have to register an account to upload anything (I think), but there are few uploaders and many downloaders, so the explanation above could still work on average.
They may well have done so. I didn't get any phone campaign phone calls this cycle, and am on the do-not-call list.
I wasn't idle, either, I donated to one of the presidential campaigns via the website. This triggered some e-mail traffic, mostly requests for further donations, but also requests for me to volunteer to make phone calls or knock on doors in a nearby swing state. Oh, and some snail-mail, they sent me a bumper-sticker.
The War of 1812 is an odd example to pick -- the summary makes it sound like it's a representative military history item for which there is lots of good scholarship, so that the readership and edit traffic numbers might generalize across other history articles.
But in fact, the War of 1812 has been getting more press lately, because it's currently the 200th anniversary. There's even a post-blog, 1812now, specifically about it, and a variety of interest-generating retrospectives in mainstream media.
Their broader point may not hold up for other, less topical pages.
This is a near-miss in the math nonfiction category, "One Jump Ahead" by Jonathan Schaeffer is the story of the guy who solved the game of checkers. I haven't read the book, but there's a podcast on the "relatively prime" series, called "Chinook", here.
Disclaimer: I am not affiliated with either the Relatively Prime podcast series, or the Chinook project.
So TFA doesn't say, but I wonder if this is includes the same "Sabatier reaction" that's part of Robert Zubrin's "Mars Direct" plan -- in the Zubrin case, you send a nuclear reactor and some hydrogen to mars, and use that plus martian CO2 and a catalyst to make methane and oxygen, which become the basis for bootstrapping your martian chemical industry.
Obviously, these guys have more dilute CO2, and their other reactant is H20, not H2, but it seems likely to be closely related.
So obviously Alan Cox is much more of an expert than I am, but I've installed the binary nVidia blob on many, many machines, so I'm aware that there is a "shim" interface layer that gets built at install-time to bridge between the closed-source nVidia stuff and the actual kernel. This shim is visible, obviously you can *read* it if you unpack nVidia's installer, and it uses kernel header files at build-time.
It seems that this has to mean that there is already a way to get closed-source binary blobs to talk to the kernel, and that nVidia already knows how to do this.
Can someone explain why this is different? Why can't the DMA-BUF code be part of the shim, or part of a different shim? It's technically more complex, but I can't believe that nVidia of all people are slowed down by some technical complexity.
This kind of "wide" multithreading of individual cores is excellent for applications which are themselves fairly lightweight but which make intensive use of devices that can have (realtively) high latency. Network file service and RAID control are both applications like this -- any given thread is likely to spend a significant fraction of its time in "device wait", waiting for a hard-drive to seek to the right sector, so its overall "duty cycle" (i.e. the fraction of its lifetime for which it needs to actually use the core's ALU) is low. But you can still increase overall throughput by handling lots of requests in parallel.
So, you want lots of threads, each with a low duty cycle, which is what this hardware does.
It's not a coincidence -- Sun invented both NFS and the SPARC chips, after all.
According to the linked-to DOE report, the guy who was fired wasn't quite as brave as the Bulletin article implies -- the DOE says he drove up to the site, stayed in his car and spoke on his cell phone with a supervisor, then got out of the car and just chatted with the protesters, failing to detain them or protect his weapon. When the supervisor arrived, the guard was instructed to provide cover for the supervisor while the supervisor made the actual arrests, but the guard did not do so, allegedly turning his back on the process at one point.
So this unit has a bit of history -- there used to be a 300-foot diameter transit telescope on the site, which collapsed in 1988. The Byrd telescope was an upgrade, being fully steerable and covering more of the spectrum. The location is fairly special too, it's in a radio-quiet zone with some other NRAO telescopes, and close to the Navy's radio observatory site.
The thing only started working in August of 2000, it seems a shame to shut it down after such a small fraction of its expected operating lifetime.
I have this issue on my Dell mini netbook, it's one of the older ones that actually shipped with Ubuntu back in early 2010.
The problem seemed to gradually get worse for a while, and at one point the graphical start-up screen stopped working, and the thing just booted in text mode. The most egregious symptoms went away with the most recent kernel update, but it's hard to tell if the hang-on-wake problem is actually fixed, because it was intermittent anyways.
> if you can't distinguish between private businesses and a government intelligence agency then, my friend, you're a moron.
Because I can always use my God-given liberty to decline to do business with Microsoft, Adobe, Apple, and so forth, but the Russian government can legitimately use force against me? That's why they have different standards of accountability, right?
If I were Russian, that might make some sense, but I'm pretty sure the Russian government can't legitimately use force against me. Declining to do business with the entire tech world is at least theoretically possible, I'll give you that, but it's so impractical that it almost doesn't matter.
This story was on the local Washington DC NPR affiliate yesterday, and they did a much better job describing the problem -- it was quite obviously a UPS bungle, underneath the address sticker on the package, there was *another* address sticker, with the address of a gun shop in Maryland, which confirmed that they had indeed ordered this thing, and were waiting for it. Amazon doesn't appear to have done anything wrong in this case.
The part that I thought NPR did poorly was, both they and the guy who was the subject of the story kept going on about how dangerous the situation was, and I thought that was kind of over-blown. It was left on his porch for a while, which put it at risk for theft, but the gun was, as far as I can tell, not loaded, and there was no suitable ammunition anywhere around. So, it seems to me that, practically speaking, it was no more or less dangerous than a similarly-sized shovel or crowbar, independently of the presence of pregnant women and other vulnerable people.
When someone shows up with the right ammo, *then* it's dangerous. But not before.
So back in the day, we had a thing called the mbone, which was multicast infrastructure which was supposed to help with streaming live content from a single sender to many receivers. It was a bit ahead of its time, I think, streaming video just wasn't that common in the 1990s, and it also really only worked for actually-simultaneous streams, which, when streaming video did become common, wasn't what people were watching.
The contemporary solution is for big content providers to co-locate caches in telco data centers, so while you still send multiple separate streams of unsynchronized, high-demand streaming content, you send them a relatively short distance over relatively fat pipes, except for the last mile, which however only has to carry one copy. For low-demand streaming content, you don't need to cache, it's only a few copies, and the regular internet mostly works. It can fall over when a previously low-demand stream suddenly becomes high-demand, like Sunday night when NASA TV started to get slow, but it mostly works.
TFA (I know, I know...) doesn't address moving data around, but it seems like this is something that a new scheme could offer -- if the co-located caches were populated based purely on demand, rather than on demand plus ownership, then all content would be on the same footing, and it could lead to a better web experience for info consumers. That's a neat idea, but I think we already know how both the telcos and commercial streaming content owners feel about demand-based dynamic copy creation...
I'll give you laggy, but locked down? For the mobile space, the Kindle Fire is mostly an ordinary Android device, except that it's got a better eReader app. You can side-load third-party apps without rooting, or you can root it and install the Google Marketplace, or so I've heard.
Of course, the general lock-downedness of the mobile space is irritating to me, but that's a separate topic.
That's a surprising answer, since I assumed you were opposed to regulation -- sorry if I misjudged your intent. Obviously, one direction one could go is to increase the oversight and penalties, which would serve to encourage maintenance. It would also let them off the hook with their shareholders -- "we wanted to skimp on maintenance to pay your dividends, but were unable to, due to regulatory constraints."
It's certainly true that the government enforces Pepco's regional monopoly, but I think there are serious technical issues associated with relaxing this -- either Pepco has to be forced to allow other utilities' revenue power to flow over their lines (more, or at least different, legislation and regulation required for that), or somebody has to pay for duplicate or triplicate infrastructure. It's largely because of these constraints that electric power generation and distribution was consolidated and regulated in the first place, of course.
I'll leave it to you to explain how the communistic socialistic regulations created incentives for Pepco (regional utility in Montgomery County, MD, site of massive outages right now) to neglect maintenance.
Remember to include the part where the regulators fined Pepco a million bucks last year, as punishment for his neglect of maintenance.
Also make sure you talk about how the regulatory regime encourages the large dividends they paid to their shareholders.
So the comments are confusing to me as to whether Debian "squeeze" is supposed to have a problem or not, but I have about fifty of these systems running, and as far as I can tell, they're all fine.
I got a whole bunch of these in the logs: > Jun 30 19:59:59 kernel: [timestamp] Clock: inserting leap second 23:59:60 UTC
I have three of the machines configured as NTP peers to each other, and looking at a few tier-1 time servers. The rest of the machines all use the three local peers as time servers.
My Debian desktop systems at home also seem to be fine.
One thing we have learned is that, in nuclear power, "not making mistakes" can cost a lot of money and take a lot of time. One of the mistakes we heard about when the Fukushima Daiichi event happened was continuing to operate these poorly-designed older-generation reactors for so long.
From the sounds of it, this new report has come out strongly in favor of not repeating that mistake, which sounds pretty logical to me.
Slashdot Mirror
> When will candidates who are actually qualified to represent science ... be the representatives of science with regard to political decision-making?
You know that Steven Chu is secretary of energy, right? And that the department of energy has a Basic Energy Sciences division which gets a lot of federal science money?
And wasn't there a slashdot story about a physicist-turned-congressman lately?
I mean, yes, I'd like it if it happened more often, and I'm not defending Lamar Smith's qualifications, but it's childish and petty to pretend that it _never_ happens.
An "x86 app" is an app that someone has compiled for x86 and only given you the binary.
Open-source apps are not generally architecture specific. If you have source code and development tools, you can build it on whatever you like, and ARM is pretty mature in this regard. Several Linux distros have ARM ports already, including Debian and Arch, and probably Fedora, and there's a FreeBSD ARM project, also, if you're allergic to the GPL.
And there is Android, for which the OS is natively ARM, even if the app-land is Java.
This ability to mix and match software and hardware in ways not anticipated by the creators of the software or the hardware is exactly why open source is awesome.
Conjecture on my part, but when you pay for an account, you give them some information, so that they can get their money. To a non-infringing free downloader, the cap is an inconvenience, and some fraction of them will be willing to pay to make it go away. To a copyright-infringing free downloader, paying to remove the cap requires them to identify, and possibly incriminate, themselves, so it's more of an obstacle.
This explanation is incomplete, of course, since presumably the uploader is also on the hook for copyright violation, and you have to register an account to upload anything (I think), but there are few uploaders and many downloaders, so the explanation above could still work on average.
It actually sort of already works in "Linux", since there's a working Netflix app for Android.
I've never done it, but presumably this means that you can run it on your Linux desktop by running an Android device emulator with the Netflix app.
They may well have done so. I didn't get any phone campaign phone calls this cycle, and am on the do-not-call list.
I wasn't idle, either, I donated to one of the presidential campaigns via the website. This triggered some e-mail traffic, mostly requests for further donations, but also requests for me to volunteer to make phone calls or knock on doors in a nearby swing state. Oh, and some snail-mail, they sent me a bumper-sticker.
But no phone calls.
The War of 1812 is an odd example to pick -- the summary makes it sound like it's a representative military history item for which there is lots of good scholarship, so that the readership and edit traffic numbers might generalize across other history articles.
But in fact, the War of 1812 has been getting more press lately, because it's currently the 200th anniversary. There's even a post-blog, 1812now, specifically about it, and a variety of interest-generating retrospectives in mainstream media.
Their broader point may not hold up for other, less topical pages.
This is a near-miss in the math nonfiction category, "One Jump Ahead" by Jonathan Schaeffer is the story of the guy who solved the game of checkers. I haven't read the book, but there's a podcast on the "relatively prime" series, called "Chinook", here.
Disclaimer: I am not affiliated with either the Relatively Prime podcast series, or the Chinook project.
So TFA doesn't say, but I wonder if this is includes the same "Sabatier reaction" that's part of Robert Zubrin's "Mars Direct" plan -- in the Zubrin case, you send a nuclear reactor and some hydrogen to mars, and use that plus martian CO2 and a catalyst to make methane and oxygen, which become the basis for bootstrapping your martian chemical industry.
Obviously, these guys have more dilute CO2, and their other reactant is H20, not H2, but it seems likely to be closely related.
If after 53 years you still haven't finished your 5-mile run, you may not be in especially good condition...
So obviously Alan Cox is much more of an expert than I am, but I've installed the binary nVidia blob on many, many machines, so I'm aware that there is a "shim" interface layer that gets built at install-time to bridge between the closed-source nVidia stuff and the actual kernel. This shim is visible, obviously you can *read* it if you unpack nVidia's installer, and it uses kernel header files at build-time.
It seems that this has to mean that there is already a way to get closed-source binary blobs to talk to the kernel, and that nVidia already knows how to do this.
Can someone explain why this is different? Why can't the DMA-BUF code be part of the shim, or part of a different shim? It's technically more complex, but I can't believe that nVidia of all people are slowed down by some technical complexity.
This kind of "wide" multithreading of individual cores is excellent for applications which are themselves fairly lightweight but which make intensive use of devices that can have (realtively) high latency. Network file service and RAID control are both applications like this -- any given thread is likely to spend a significant fraction of its time in "device wait", waiting for a hard-drive to seek to the right sector, so its overall "duty cycle" (i.e. the fraction of its lifetime for which it needs to actually use the core's ALU) is low. But you can still increase overall throughput by handling lots of requests in parallel.
So, you want lots of threads, each with a low duty cycle, which is what this hardware does.
It's not a coincidence -- Sun invented both NFS and the SPARC chips, after all.
According to the linked-to DOE report, the guy who was fired wasn't quite as brave as the Bulletin article implies -- the DOE says he drove up to the site, stayed in his car and spoke on his cell phone with a supervisor, then got out of the car and just chatted with the protesters, failing to detain them or protect his weapon. When the supervisor arrived, the guard was instructed to provide cover for the supervisor while the supervisor made the actual arrests, but the guard did not do so, allegedly turning his back on the process at one point.
DOE report here (warning, PDF).
It's obviously a contested point, but the pictures painted by the Bulletin article and the DOE report of the guard's conduct are rather different.
Also, yes, I read both articles, new here, etc.etc.
So this unit has a bit of history -- there used to be a 300-foot diameter transit telescope on the site, which collapsed in 1988. The Byrd telescope was an upgrade, being fully steerable and covering more of the spectrum. The location is fairly special too, it's in a radio-quiet zone with some other NRAO telescopes, and close to the Navy's radio observatory site.
The thing only started working in August of 2000, it seems a shame to shut it down after such a small fraction of its expected operating lifetime.
I have this issue on my Dell mini netbook, it's one of the older ones that actually shipped with Ubuntu back in early 2010.
The problem seemed to gradually get worse for a while, and at one point the graphical start-up screen stopped working, and the thing just booted in text mode. The most egregious symptoms went away with the most recent kernel update, but it's hard to tell if the hang-on-wake problem is actually fixed, because it was intermittent anyways.
> if you can't distinguish between private businesses and a government intelligence agency then, my friend, you're a moron.
Because I can always use my God-given liberty to decline to do business with Microsoft, Adobe, Apple, and so forth, but the Russian government can legitimately use force against me? That's why they have different standards of accountability, right?
If I were Russian, that might make some sense, but I'm pretty sure the Russian government can't legitimately use force against me. Declining to do business with the entire tech world is at least theoretically possible, I'll give you that, but it's so impractical that it almost doesn't matter.
> What's it like to have knowledge that you don't understand? That concept doesn't make sense to me.
That would be like if someone told you about a concept, so you knew it existed, but it didn't make sense to you.
This story was on the local Washington DC NPR affiliate yesterday, and they did a much better job describing the problem -- it was quite obviously a UPS bungle, underneath the address sticker on the package, there was *another* address sticker, with the address of a gun shop in Maryland, which confirmed that they had indeed ordered this thing, and were waiting for it. Amazon doesn't appear to have done anything wrong in this case.
The part that I thought NPR did poorly was, both they and the guy who was the subject of the story kept going on about how dangerous the situation was, and I thought that was kind of over-blown. It was left on his porch for a while, which put it at risk for theft, but the gun was, as far as I can tell, not loaded, and there was no suitable ammunition anywhere around. So, it seems to me that, practically speaking, it was no more or less dangerous than a similarly-sized shovel or crowbar, independently of the presence of pregnant women and other vulnerable people.
When someone shows up with the right ammo, *then* it's dangerous. But not before.
So back in the day, we had a thing called the mbone, which was multicast infrastructure which was supposed to help with streaming live content from a single sender to many receivers. It was a bit ahead of its time, I think, streaming video just wasn't that common in the 1990s, and it also really only worked for actually-simultaneous streams, which, when streaming video did become common, wasn't what people were watching.
The contemporary solution is for big content providers to co-locate caches in telco data centers, so while you still send multiple separate streams of unsynchronized, high-demand streaming content, you send them a relatively short distance over relatively fat pipes, except for the last mile, which however only has to carry one copy. For low-demand streaming content, you don't need to cache, it's only a few copies, and the regular internet mostly works. It can fall over when a previously low-demand stream suddenly becomes high-demand, like Sunday night when NASA TV started to get slow, but it mostly works.
TFA (I know, I know...) doesn't address moving data around, but it seems like this is something that a new scheme could offer -- if the co-located caches were populated based purely on demand, rather than on demand plus ownership, then all content would be on the same footing, and it could lead to a better web experience for info consumers. That's a neat idea, but I think we already know how both the telcos and commercial streaming content owners feel about demand-based dynamic copy creation...
A true scotsman wouldn't make such a fuss about it...
I'll give you laggy, but locked down? For the mobile space, the Kindle Fire is mostly an ordinary Android device, except that it's got a better eReader app. You can side-load third-party apps without rooting, or you can root it and install the Google Marketplace, or so I've heard.
Of course, the general lock-downedness of the mobile space is irritating to me, but that's a separate topic.
That's a surprising answer, since I assumed you were opposed to regulation -- sorry if I misjudged your intent. Obviously, one direction one could go is to increase the oversight and penalties, which would serve to encourage maintenance. It would also let them off the hook with their shareholders -- "we wanted to skimp on maintenance to pay your dividends, but were unable to, due to regulatory constraints."
It's certainly true that the government enforces Pepco's regional monopoly, but I think there are serious technical issues associated with relaxing this -- either Pepco has to be forced to allow other utilities' revenue power to flow over their lines (more, or at least different, legislation and regulation required for that), or somebody has to pay for duplicate or triplicate infrastructure. It's largely because of these constraints that electric power generation and distribution was consolidated and regulated in the first place, of course.
I'll leave it to you to explain how the communistic socialistic regulations created incentives for Pepco (regional utility in Montgomery County, MD, site of massive outages right now) to neglect maintenance.
Remember to include the part where the regulators fined Pepco a million bucks last year, as punishment for his neglect of maintenance.
Also make sure you talk about how the regulatory regime encourages the large dividends they paid to their shareholders.
So the comments are confusing to me as to whether Debian "squeeze" is supposed to have a problem or not, but I have about fifty of these systems running, and as far as I can tell, they're all fine.
I got a whole bunch of these in the logs:
> Jun 30 19:59:59 kernel: [timestamp] Clock: inserting leap second 23:59:60 UTC
I have three of the machines configured as NTP peers to each other, and looking at a few tier-1 time servers. The rest of the machines all use the three local peers as time servers.
My Debian desktop systems at home also seem to be fine.
> I recall Voyager...
Viking, and it wasn't looking for carbon, specifically, it was looking for long-chain hydrocarbons. Good link here.
One thing we have learned is that, in nuclear power, "not making mistakes" can cost a lot of money and take a lot of time. One of the mistakes we heard about when the Fukushima Daiichi event happened was continuing to operate these poorly-designed older-generation reactors for so long.
From the sounds of it, this new report has come out strongly in favor of not repeating that mistake, which sounds pretty logical to me.