We can't know how many sunspots there really are if we're only seeing only half the surface of our star, right?
We see more than half of the surface.
A technique called "helioseismic holography" can detect sunspots on the far side of the sun. There is also a pair of spacecraft called STEREO which are in a solar orbit that lets them see parts of the sun that are not visible from earth.
So I don't know much about openmoko, but you're saying that if you let the battery go to 0% that would brick the phone?
Not "bricked", it just won't power on unless you put in a battery that is not completely discharged (you can borrow a Nokia BL-*C from someone if you don't have another battery). This only affects the first batch of units ("A5"), and can be worked around in software by programming the PMU to charge the battery at 100mA when the device is off.
Planar speakers have been around for decades. Magnepan is one of the oldest, along with Martin Logan, Quad, SoundLab and the defunct Apogee. Sota and Monsoon also made planars for a while.
Yup. I was one of the people who designed and built the Monsoon-branded planar magnetic speakers. Some of the technology was licensed from http://www.eminent-tech.com/main.html.
We also looked at electrostatic speakers, including the "two sheets of conductive material with a compliant spacer" variety. It's easy to make a proof-of-concept device that makes some sound, much harder to do it properly. Problems include:
- High voltages (10s to 100s of volts) required, difficult to produce and a potential safety issue for consumer products.
- Air is surprisingly incompressible when you're dealing with small volumes.
- A single-sided electrostatic speaker is non-linear. As the two plates of the capacitor get closer, the capacitance and the attractive force increase.
- It's hard to get decent bass out of a planar speaker. The coupling to the air drops off very sharply below a certain frequency (depending on the size of the panel).
Did you know if you dump some instant grits on a fire ant mound the workers will take them in and feed them to the queen, and that she will then die as they slowly expand in her body,
I've been reading Slashdot for many years and I've seen a lot of comments about grits, but that one's new to me.
fsync() is for flushing *all* data to disk. That's often the wrong thing to do! If the application just needs to flush it's own writes to disk, or even just one specific write, and not incur the HUGE performance hit of fsync(), it shouldn't need to call fsync().
sync() is for flushing *all* data to disk.
fsync() and the related fdatasync() operate on a single file descriptor. There is also a finer-grained, non-portable "sync_file_range()" introduced in kernel 2.6.17 (according to the man page).
fsync() is the correct function call for an application to use when it wants to flush its writes (for a particular fd) to disk. It is unfortunate if the implementation cannot do so without having to also flush unrelated writes to disk, but that's beyond the control of a userspace application.
Some of us have discovered the 'shutdown' command. [...]Anyhow, I suggest you use it occasionally. Then perhaps you can only fsck when something bad has happened.
Don't be too smug - a "shutdown" doesn't always guarantee a clean startup. I remember a bug (hopefully fixed now) where "shutdown" was completing so quickly that it powered off the computer while data was still sitting in the hard drive's volatile write cache. Even though the OS had unmounted the filesystem, the on-disk blocks were still dirty.
p.s. If any OS/kernel developers are listening - how about implementing a standard API through which drive write-caches can be flushed+disabled whenever a system starts a shutdown procedure, gets a signal that the UPS is running on battery power, or otherwise concludes that it is in a state where a temporarily-increased risk of data loss justifies slowing down I/O?
- Make regular backups; you'll need them eventually. Keep some off-site. - ext3 filesystem, default "data=ordered" journal - Disable the on-drive write-cache with 'hdparm' - "dirsync" mount option - Consider a "relatime" or "noatime" mount option to increase performance (depending on whether or not you use applications that care about atime) - If you don't want the performance hit from disabling the on-drive write-cache, add a UPS and set up software to shut down your system cleanly when the power fails. You are still vulnerable to power-supply failures etc. even if you have a UPS. - Schedule regular "smartctl" scans to detect low-level drive failures - Schedule regular RAID parity checks (triggered through a "/sys/.../sync_action" node) to look for inconsistencies. I have a software-RAID1 mirror and I've found problems here a few times (one of which was that 'grub' had written to only one of the disks of the md device for my/boot partition). - Periodically compare the current filesystem contents against one of your old backups. Make sure that the only files that are different are ones that you expected to be different.
If you decide to use ext4 or XFS most of the above points will still apply. I don't have any experience with ext4 yet so I can't say how well it compares to ext3 in terms of data-preservation.
ISTR firmware viruses infecting C64 floppy disk drives......
Nothing that would survive a power-cycle, though. That was before we had flash memory - it was either true ROMs or UV-erasable EPROMs.
Flash that can be re-programmed by "in-band" communication (vs. a dedicated maintenance channel like JTAG) is convenient but it is also very risky. I'm glad to see that this issue is getting more publicity. Maybe now we'll see a shift back to hardware write-protection, like a physical jumper inside the PC that has to be connected before you can re-flash the BIOS.
It's not just BIOS either. Your hard drive has reprogrammable firmware (see the recent Seagate bugs). Your wireless adapters (including bluetooth) may have reprogrammable firmware. There's plenty of opportunity for someone with the right knowledge to compromise your system.
The voters thought that the screen that came up after they clicked "Vote" was their confirmation that the vote had been cast. They left without thinking anything was wrong, just like the Florida voters who mis-punched their famous butterfly ballots in 2000.
No voting system is going to let you leave with a paper receipt showing how you voted. That is too vulnerable to abuse.
, the Election Day scheme, carried out in primary and general elections in at least 2004 and 2006, was accomplished by taking advantage of a "feature" on all DRE (usually touch-screen) voting systems and "voter unfamiliarity with new voting machines."
Essentially, they tricked voters into leaving the 'booth' after pressing the "Vote" button on the ES&S iVotronic. That button, does not actually cast the vote, as one might think (and as these voters were told), but instead, it brings up a review screen of the voter's "ballot."
So this looks like basic social engineering, not exploiting any specific flaws of the electronic machine (other than poor UI design).
Hey, I can do better than that. I can "build" my own solar panels for just the cost of a crowbar and a ladder by ripping them off my neighbor's roof and then soldering new wires to them.
A capacitor would probably have enough juice to do an emergency flush of the cache without wearing out like a battery. I am not an electrical engineer.
The battery is not there to do an emergency flush. It's to preserve the data in RAM for a couple of days until main power is restored. Once that happens and the disks spin up again the cached data is written out. There has been a huge improvement in capacitors over the years but they still do not have the same energy density as a good battery.
One approach that I think would be viable would be to have a capacitor and some flash memory on the controller card. In the event of a power failure the capacitor would only have to supply power long enough for the controller to copy all of the RAM into flash. I don't know if anybody is producing this yet but it seems like an obvious step now that flash is dirt-cheap.
He posed the question, if you were in the woods with nothing but a hatchet, how long before you could send an email?
As long as it takes for some hiker with a smartphone to come by, plus a few minutes to clean the blood off the hatchet.
This device may not compare favorably with commercially available computing platforms, but having people in our society with curious minds and an ability to make things is invaluable.
Agreed - this is a very cool project.
I have recently been working with amateur packet radio, which is somewhere in between the linked project and modern technology. In addition to a computer you only need a radio transceiver and some simple circuitry connecting it to the audio in/out ports, and you can send email to a similarly-equipped station within the range of your radio (at speeds between 300 and 9600 baud). There are people who build their own radios and adapters but I'm doing it the easy way with commercial units.
As a more serious answer to your "alone in the woods" question, someone with the right skills could actually get a morse code transmitter running with some surprisingly low-tech materials. Look here for example - you don't even need a transistor or vacuum tube.
First, there's no fundamental difference between "code" and "data". It's all binary blob
That's true on a von Neumann architecture. A Harvard architecture CPU (used in some microcontrollers) has a stricter separation between the two concepts.
Can I assume that you're upset about HTML having all this stupid Javascript stuff, too?
I can't speak for the original poster, but I'm certainly happier since I installed the NoScript extension in Firefox. Slashdot was one of the main reasons that I installed it, as there was some script on the front page that used to freeze my browser for a few seconds for no good reason.
In a PDF "document" I sure as hell don't want any active scripts beyond the ones that are needed to generate the pixels I'm looking at. I can see a use for interactive forms and similar scripted things, but they should not be lumped into the same category as read-only documents.
Buy an A1000 and run some graphics demos on one. Then try to remember that it was made in 1985.
Remember also that many of the main features of Microsoft's Windows 95 (32-bit code, preemptive multitasking, long-filename support) were present in the original "Amiga 85" OS.
Now explain flash/solid state memory sizes and the "formatted capacity" of memory.
At a low level flash chips have a row/column nature similar to DRAM, but there is additional complexity because some operations target a larger "erase block" rather than an individual byte.
Some embedded platforms present a raw interface to the flash memory and require the host operating system to provide support for bad blocks and wear-levelling. These would be specified in "MiB" along with a certain allowable percentage of bad blocks.
However, the more familiar approach (e.g. in a SD card) is to include an embedded microcontroller that presents a logical block interface to the host. This controller skips over the bad blocks, and also needs to use some of the good blocks to keep track of the logical-to-physical block mapping. Here it makes more sense to use SI notation.
I just checked an "8 GB" microSD card and found that it presents a capacity of 7969177600 bytes to the OS (before partitioning). So 0.4% of the rated capacity is not available to me. This is consistent with the typical fine print on the package, e.g. "Some of the listed capacity is used for formatting and other functions, and thus is not available for data storage" (from Sandisk's website). If the manufacturer had sold it as an "8 GiB" card I would be more upset because that would represent a 7.3% capacity loss.
Your argument would carry more weight if the manufacturers were doing this for the benefit of humans. In fact, they mix units - using the 1024-standard units for cache.
RAM specifications use the 2^x numbering because the device is physically constructed as a square grid of cells with power-of-two numbers of rows and columns. There's a direct mapping between bits on the address bus and the cell that is selected.
In the early days it was convenient to say that 1024 was close enough to 1000, so RAM sizes were quoted in "KB". However, the error in this increases with each step up in size. By the time you get to the TB scale it's no longer a reasonable approximation.
Magnetic storage does not have this constraint. The sector size is (arbitrarily) set at 512 bytes and hard drives usually have an even number of read/write heads, but apart from that there are no powers of two. The number of cylinders on the drive, and the number of sectors per cylinder, are arbitrary.
Communication speeds (e.g. "9600 baud", "100 Mb/s") are also not specified in power-of-two sizes, because they are natively dealing with individual bits and not power-of-two-sized chunks.
Therefore, there is nothing wrong with saying that a drive is "1 TB with 32 MiB of cache". As long as the manufacturer uses the SI and kilobinary notation correctly, users should not complain. Save your anger for the marketroids at WD who come up with features like "IntelliSpeed" in order to sell you a 5400-RPM drive and make you think you're buying a 7200-RPM one.
tl;dr version: Just use the damn GiB/GB notation consistently and get over it.
http://qpxtool.sourceforge.net - Linux program for performing low-level quality measurements on CDs and DVDs. It only works with some drive models, so check the supported hardware list.
Slashdot Mirror
We can't know how many sunspots there really are if we're only seeing only half the surface of our star, right?
We see more than half of the surface.
A technique called "helioseismic holography" can detect sunspots on the far side of the sun. There is also a pair of spacecraft called STEREO which are in a solar orbit that lets them see parts of the sun that are not visible from earth.
So I don't know much about openmoko, but you're saying that if you let the battery go to 0% that would brick the phone?
Not "bricked", it just won't power on unless you put in a battery that is not completely discharged (you can borrow a Nokia BL-*C from someone if you don't have another battery). This only affects the first batch of units ("A5"), and can be worked around in software by programming the PMU to charge the battery at 100mA when the device is off.
Planar speakers have been around for decades. Magnepan is one of the oldest, along with Martin Logan, Quad, SoundLab and the defunct Apogee. Sota and Monsoon also made planars for a while.
Yup. I was one of the people who designed and built the Monsoon-branded planar magnetic speakers. Some of the technology was licensed from http://www.eminent-tech.com/main.html.
We also looked at electrostatic speakers, including the "two sheets of conductive material with a compliant spacer" variety. It's easy to make a proof-of-concept device that makes some sound, much harder to do it properly. Problems include:
- High voltages (10s to 100s of volts) required, difficult to produce and a potential safety issue for consumer products.
- Air is surprisingly incompressible when you're dealing with small volumes.
- A single-sided electrostatic speaker is non-linear. As the two plates of the capacitor get closer, the capacitance and the attractive force increase.
- It's hard to get decent bass out of a planar speaker. The coupling to the air drops off very sharply below a certain frequency (depending on the size of the panel).
Did you know if you dump some instant grits on a fire ant mound the workers will take them in and feed them to the queen, and that she will then die as they slowly expand in her body,
I've been reading Slashdot for many years and I've seen a lot of comments about grits, but that one's new to me.
fsync() is for flushing *all* data to disk. That's often the wrong thing to do! If the application just needs to flush it's own writes to disk, or even just one specific write, and not incur the HUGE performance hit of fsync(), it shouldn't need to call fsync().
sync() is for flushing *all* data to disk.
fsync() and the related fdatasync() operate on a single file descriptor. There is also a finer-grained, non-portable "sync_file_range()" introduced in kernel 2.6.17 (according to the man page).
fsync() is the correct function call for an application to use when it wants to flush its writes (for a particular fd) to disk. It is unfortunate if the implementation cannot do so without having to also flush unrelated writes to disk, but that's beyond the control of a userspace application.
Some of us have discovered the 'shutdown' command. [...]Anyhow, I suggest you use it occasionally. Then perhaps you can only fsck when something bad has happened.
Don't be too smug - a "shutdown" doesn't always guarantee a clean startup. I remember a bug (hopefully fixed now) where "shutdown" was completing so quickly that it powered off the computer while data was still sitting in the hard drive's volatile write cache. Even though the OS had unmounted the filesystem, the on-disk blocks were still dirty.
p.s. If any OS/kernel developers are listening - how about implementing a standard API through which drive write-caches can be flushed+disabled whenever a system starts a shutdown procedure, gets a signal that the UPS is running on battery power, or otherwise concludes that it is in a state where a temporarily-increased risk of data loss justifies slowing down I/O?
Even better: use barriers (not enabled by default on ext3, not sure about ext4).
Won't work through LVM or the software-RAID layer, unless this has changed recently.
My advice:
- Make regular backups; you'll need them eventually. Keep some off-site. /boot partition).
- ext3 filesystem, default "data=ordered" journal
- Disable the on-drive write-cache with 'hdparm'
- "dirsync" mount option
- Consider a "relatime" or "noatime" mount option to increase performance (depending on whether or not you use applications that care about atime)
- If you don't want the performance hit from disabling the on-drive write-cache, add a UPS and set up software to shut down your system cleanly when the power fails. You are still vulnerable to power-supply failures etc. even if you have a UPS.
- Schedule regular "smartctl" scans to detect low-level drive failures
- Schedule regular RAID parity checks (triggered through a "/sys/.../sync_action" node) to look for inconsistencies. I have a software-RAID1 mirror and I've found problems here a few times (one of which was that 'grub' had written to only one of the disks of the md device for my
- Periodically compare the current filesystem contents against one of your old backups. Make sure that the only files that are different are ones that you expected to be different.
If you decide to use ext4 or XFS most of the above points will still apply. I don't have any experience with ext4 yet so I can't say how well it compares to ext3 in terms of data-preservation.
ISTR firmware viruses infecting C64 floppy disk drives......
Nothing that would survive a power-cycle, though. That was before we had flash memory - it was either true ROMs or UV-erasable EPROMs.
Flash that can be re-programmed by "in-band" communication (vs. a dedicated maintenance channel like JTAG) is convenient but it is also very risky. I'm glad to see that this issue is getting more publicity. Maybe now we'll see a shift back to hardware write-protection, like a physical jumper inside the PC that has to be connected before you can re-flash the BIOS.
It's not just BIOS either. Your hard drive has reprogrammable firmware (see the recent Seagate bugs). Your wireless adapters (including bluetooth) may have reprogrammable firmware. There's plenty of opportunity for someone with the right knowledge to compromise your system.
The voters thought that the screen that came up after they clicked "Vote" was their confirmation that the vote had been cast. They left without thinking anything was wrong, just like the Florida voters who mis-punched their famous butterfly ballots in 2000.
No voting system is going to let you leave with a paper receipt showing how you voted. That is too vulnerable to abuse.
From the article:
, the Election Day scheme, carried out in primary and general elections in at least 2004 and 2006, was accomplished by taking advantage of a "feature" on all DRE (usually touch-screen) voting systems and "voter unfamiliarity with new voting machines."
Essentially, they tricked voters into leaving the 'booth' after pressing the "Vote" button on the ES&S iVotronic. That button, does not actually cast the vote, as one might think (and as these voters were told), but instead, it brings up a review screen of the voter's "ballot."
So this looks like basic social engineering, not exploiting any specific flaws of the electronic machine (other than poor UI design).
Hey, I can do better than that. I can "build" my own solar panels for just the cost of a crowbar and a ladder by ripping them off my neighbor's roof and then soldering new wires to them.
Lame article. Wake me when someone actually makes their own solar cells at the $/W of a commercial unit.
A capacitor would probably have enough juice to do an emergency flush of the cache without wearing out like a battery. I am not an electrical engineer.
The battery is not there to do an emergency flush. It's to preserve the data in RAM for a couple of days until main power is restored. Once that happens and the disks spin up again the cached data is written out. There has been a huge improvement in capacitors over the years but they still do not have the same energy density as a good battery.
One approach that I think would be viable would be to have a capacitor and some flash memory on the controller card. In the event of a power failure the capacitor would only have to supply power long enough for the controller to copy all of the RAM into flash. I don't know if anybody is producing this yet but it seems like an obvious step now that flash is dirt-cheap.
He posed the question, if you were in the woods with nothing but a hatchet, how long before you could send an email?
As long as it takes for some hiker with a smartphone to come by, plus a few minutes to clean the blood off the hatchet.
This device may not compare favorably with commercially available computing platforms, but having people in our society with curious minds and an ability to make things is invaluable.
Agreed - this is a very cool project.
I have recently been working with amateur packet radio, which is somewhere in between the linked project and modern technology. In addition to a computer you only need a radio transceiver and some simple circuitry connecting it to the audio in/out ports, and you can send email to a similarly-equipped station within the range of your radio (at speeds between 300 and 9600 baud). There are people who build their own radios and adapters but I'm doing it the easy way with commercial units.
As a more serious answer to your "alone in the woods" question, someone with the right skills could actually get a morse code transmitter running with some surprisingly low-tech materials. Look here for example - you don't even need a transistor or vacuum tube.
It seems to me the LCD panel/backlight are by far the biggest consumer of battery power.
Don't forget that the XO screen has a monochrome no-backlight (reflective) mode.
First, there's no fundamental difference between "code" and "data". It's all binary blob
That's true on a von Neumann architecture. A Harvard architecture CPU (used in some microcontrollers) has a stricter separation between the two concepts.
Can I assume that you're upset about HTML having all this stupid Javascript stuff, too?
I can't speak for the original poster, but I'm certainly happier since I installed the NoScript extension in Firefox. Slashdot was one of the main reasons that I installed it, as there was some script on the front page that used to freeze my browser for a few seconds for no good reason.
In a PDF "document" I sure as hell don't want any active scripts beyond the ones that are needed to generate the pixels I'm looking at. I can see a use for interactive forms and similar scripted things, but they should not be lumped into the same category as read-only documents.
Buy an A1000 and run some graphics demos on one. Then try to remember that it was made in 1985.
Remember also that many of the main features of Microsoft's Windows 95 (32-bit code, preemptive multitasking, long-filename support) were present in the original "Amiga 85" OS.
I'd very much like a sentry gun that would squirt the @#$%@#@ deer with water (at least) when they come to eat the plants on the front porch.
You can get something like that here, although it's just a simple motion sensor rather than an active tracking platform.
That said, as it become more mainstream it will draw people less screwed up. What the industry really needs is a union.
Bad idea - you'd end up with all of the acting jobs going to the women with the most seniority.
Now explain flash/solid state memory sizes and the "formatted capacity" of memory.
At a low level flash chips have a row/column nature similar to DRAM, but there is additional complexity because some operations target a larger "erase block" rather than an individual byte.
Some embedded platforms present a raw interface to the flash memory and require the host operating system to provide support for bad blocks and wear-levelling. These would be specified in "MiB" along with a certain allowable percentage of bad blocks.
However, the more familiar approach (e.g. in a SD card) is to include an embedded microcontroller that presents a logical block interface to the host. This controller skips over the bad blocks, and also needs to use some of the good blocks to keep track of the logical-to-physical block mapping. Here it makes more sense to use SI notation.
I just checked an "8 GB" microSD card and found that it presents a capacity of 7969177600 bytes to the OS (before partitioning). So 0.4% of the rated capacity is not available to me. This is consistent with the typical fine print on the package, e.g. "Some of the listed capacity is used for formatting and other functions, and thus is not available for data storage" (from Sandisk's website). If the manufacturer had sold it as an "8 GiB" card I would be more upset because that would represent a 7.3% capacity loss.
Your argument would carry more weight if the manufacturers were doing this for the benefit of humans. In fact, they mix units - using the 1024-standard units for cache.
RAM specifications use the 2^x numbering because the device is physically constructed as a square grid of cells with power-of-two numbers of rows and columns. There's a direct mapping between bits on the address bus and the cell that is selected.
In the early days it was convenient to say that 1024 was close enough to 1000, so RAM sizes were quoted in "KB". However, the error in this increases with each step up in size. By the time you get to the TB scale it's no longer a reasonable approximation.
Magnetic storage does not have this constraint. The sector size is (arbitrarily) set at 512 bytes and hard drives usually have an even number of read/write heads, but apart from that there are no powers of two. The number of cylinders on the drive, and the number of sectors per cylinder, are arbitrary.
Communication speeds (e.g. "9600 baud", "100 Mb/s") are also not specified in power-of-two sizes, because they are natively dealing with individual bits and not power-of-two-sized chunks.
Therefore, there is nothing wrong with saying that a drive is "1 TB with 32 MiB of cache". As long as the manufacturer uses the SI and kilobinary notation correctly, users should not complain. Save your anger for the marketroids at WD who come up with features like "IntelliSpeed" in order to sell you a 5400-RPM drive and make you think you're buying a 7200-RPM one.
tl;dr version: Just use the damn GiB/GB notation consistently and get over it.
I have always wondered are there generators that can run off (for those that have it) natural gas or propane?
Yes, and you can even get ones designed to provide heat / hot water as well. Link.
I think $3.5M is worth more than the current outstanding SCO stocks on the market. :)
Yahoo Finance shows SCOXQ.PK at $0.13, with a market cap of 2.81M.
http://qpxtool.sourceforge.net - Linux program for performing low-level quality measurements on CDs and DVDs. It only works with some drive models, so check the supported hardware list.