Posts by Bill Gray 375 publicly visible posts • joined 12 Aug 2014
There's no way they could be reported as still being in the server room. It would have been an arithmetic impossibility.
A mathematician, engineer, and a biologist are sitting outside a house they know to be empty. They see two people go in, and three come out.
Engineer : "Our initial count must have been wrong."
Biologist : "They must have reproduced."
Mathematician : "If somebody goes into the house now, it'll be empty."
Similar issues have arisen with several other returning interplanetary spacecraft (OSIRIS-REx, Hayabusa 2, EPOXI, and probably others I'm not immediately recalling.) Some got pretty far along before their artificial nature was figured out.
On July 5-6, JUICE was imaged by the asteroid defense surveys as a "rock", with about a 10% chance of hitting the earth. Worse, we only saw it because it was glinting off the solar panels, making it look like a pretty big rock (about 50m across). Fortunately, we figured it out quickly, before it became public. Some details here (relevant bits about halfway down the post).
Hmmm... so, fewer integers, fewer rational fractions, less real numbers, less transcendental numbers?
(tl;dr : I think the need to maintain the existing format is probably the killer.)
> I am not a developer, and very definitely not of parallel code
I am a developer, but have only had a few projects involving parallel code. Just enough to be dangerous.
> How do you allocate a continuous stream to an unknown number of cores?
That part is fairly routine, and there are several ways to do it. You can just pick a number of threads to run. Pick too many, and the OS is quite good at scheduling them to spread out the load evenly. Best not to have more threads than the machine has cores, just to avoid the (small) overhead of added threads.
> When decompressing how do you coordinate who is writing which parts of the output stream -- bear in mind this is not a file-based system -- without expensive IPC or locking?
Hmmm... the loop I'm envisioning is :
While data is coming in :
Do we have (say) half a gigabyte, or whatever our block size is?
If so, start a new thread or process (probably thread) to compress said half gigabyte.
Has the thread processing the "oldest" block completed, with all preceding blocks (if any) written?
If so, start a new thread to output its data.
Both threads and forking new processes, by the way, are quite cheap in Linux. The above could be streamlined with a bit of IPC; the only "communication" in the above is a thread signalling completion. Pretty simple as it is, though.
> When compressing, how do you ensure that concurrent threads use the same encoding patterns? Note that all can be assumed to be receiving different data.
Not sure I follow you here. Of course the threads will each be compressing different data; the alternative would be that we've been conveniently handed data that repeats for each block. Different data means a different encoding pattern for each block.
> Also note you can't change the pattern used in existing formats: the format was set 13Y ago.
I'd ass umed that the format was block-based. Or, at the very least, you could say "here's a chunk of data to compress/decompress, and here's another chunk, and..." It isn't. To make it such would require a format change. Not much of one, and there's a 'version' flag that would allow for it. As an admittedly minor side benefit, such a change would mean that if you needed to decompress only part of a file, you could do so.
It would not be completely impossible to do it the way I've described and stay with the existing format. Each block would need some data from the end of the preceding block, because the compression mostly consists of saying "copy N bytes from delta_bytes ago". But it does raise the level of difficulty a fair bit.
...and am probably embarrassing myself here. But, in the spirit of "the only dumb question is the one you don't ask"...
You have (say) five GBytes to compress, and (say) four cores to devote to the job. One core compresses the first 1.25 GBytes, while another simultaneously compresses the next 1.25 GBytes, etc. Write out all four compressed chunks.
When it comes time to decompress, each of four cores is assigned a 1.25-GByte block to decompress.
Some very slight amount of decompression may be lost, if (for example) you're at the two-GByte point (partway through the second block) and some text repeats that was somewhere in the first block. You won't be able to say "copy N bytes from a gigabyte ago". In the pathological case where the file consists of a single one-GByte block repeated five times (or similar), you'll get almost no compression. (The "traditional" method would compress the last four repetitions down to just about zero.)
Aside from such unusual cases, I'm not seeing the downside.
In reality, you would say "we'll do 0.5-GByte chunks, feed cores 0-3 a half gig each, and as each finishes, feed them another half gig until the file's done." With the chunk size being a tunable parameter. This also helps in the streaming case; as soon as a half gigabyte is read, a core can start tearing into it while the next half gig is read.
As noted, if it were this easy, it'd be done this way. So what am I overlooking? (Need a head-scratching icon for this... we had the Paris one, but unlike Bogart, we won't "always have Paris".)
(for all the Ranger missions, and some interesting documentation from that time) are at https://www.lpi.usra.edu/resources/ranger/. Same page has some links to images from the Surveyor, Apollo, and Lunar Orbiter missions.
The Lunar Reconnaissance Orbiter images are much better, of course, but I gather the old data are still sometimes consulted to see what's changed in the intervening ~60 years.
Ah, thank you... I'd remembered the comment, but not where I'd read it. I should have guessed, though; much of my knowledge of Texas politics came from reading Molly Ivins (I don't live anywhere near Texas).
Decades back when one could say such things, a Texas politician (supposedly) said : "If you can't take their money, drink their booze, screw their women, and still vote against 'em, you don't belong in the Texas Legislature."
*Is it just me, or have they changed the CDM recipe in the last 10 years or so?
I read that as CDM = cold dark matter. The cosmologists have certainly come up with various ideas about the recipe for CDM over the last decade. I don't think the actual recipe has changed in the last 13.8 billion years, though, just our ideas of what that recipe might be.
"...Thats (sic) runbish (sic)..."
Important lesson I've frequently wished I could pound into somebody's head (hence icon, would be clue-by-four were such an icon available) : "Works on my machine" is not the same as "there's not a problem".
It does work on my machine, and am sure it does on yours, too. I'll bet it works properly on >99% of machines; it's hard to imagine a bug of that magnitude slipping through otherwise. (*)
The failure on five machines is interesting, though. Are there differences between them? What's the common factor explaining why Ian sees this repeatedly and most of the world doesn't see it at all?
(*) I say that, but... it's happened often that I've fixed bug X that I've heard about from one user, mention it in release notes, and then hear from a few dozen people who ran into exactly that bug, sometimes years back, but had assumed I already knew about it.
...It said real adversaries may have instead used prolonged password-praying attacks...
"God(s/ess/esses), if you really exist and love me, prove it by giving me the password to this system."
That would be a tough one to patch against. Maybe pray to your pantheon to protect your systems?
Just to be clear : we've gotten plenty of data on this guy in the last few days. It'll be the brightest near-earth object in about the last dozen years or so, reaching binocular visibility for folks in the southern hemisphere (and a few of us northerners) on 29 June. Perigee will be at about 295000 +/- 600 km at 13:41 UTC on the 29th, and there is zero probability of an impact on the current pass.
The brightness is partly due to being close and somewhat big, but also because the geometry is good (i.e., it's opposite the sun and therefore fully illuminated.)
The main event, though, will be the passage of Apophis in 2029, which will be clearly visible to the naked eye.
I doubt that any Earth-bound of orbiting RADAR could be as good as a high resolution telescope using reflected sunlight.
You are correct. Radar, including Arecibo, has discovered a total of exactly zero asteroids. It does an excellent job of measuring distance and radial velocity and physical properties, but its role is not in discovery. It needs a pretty good orbit (based on optical data) before it can detect an asteroid. (After that, the precision of the orbit increases tremendously.)
The problem is that radar drops as the inverse fourth power of distance. This is why the military radars tracking space junk can see ~10cm objects in low earth orbit, but struggle to detect much past geostationary orbit (they track only a few of the larger objects by radar).
Obviously, mileage will vary, and it sounds as if yours has been very different from mine (and many other commentards).
I've had dual-monitor systems for maybe fifteen years now. At first, I either couldn't get it to work or could only do so if they were identical. (Should note that I didn't try all that hard to figure out the configuration files.) Embarrassingly, it _did_ work on Windows ME (the last version I used before switching to Linux).
But after maybe a couple of years, across a variety of distros and configurations, including different-sized monitors and/or one monitor in portrait mode and one in landscape (my usual preference), it all Just Worked™, with nearly "grandma-friendly" levels of simplicity. I remain ignorant of xorg.conf, simply because nothing broke.
As I write this, though, it occurs to me that all my systems are at least a few years old (I salvage rather than buy new), and have one multi-head graphics card. I wonder if you were using modern hardware and/or multiple graphics cards?
If Lynch is convicted, you could say that both sides did lose. HP lost a lot of money, and Autonomy folks went to/will go to jail.
I do understand the "what-about-ism" prevalent in many comments here (i.e., "HP should have known better"). But as is routinely pointed out for smaller-scale cons, you can't use the fact that your victim was utterly foolish as a valid defense in court. (On El Reg fora, it may be a different matter.)
Can't remember for which article El Reg provided this helpful graphic. (I live in the northeastern US, not much better overall in that regard...)
I vaguely recall that Leviticus requires your slaves to come from other lands. Which does suggest that slaves from other lands are fine. US Southerners were/are mostly correct in saying that slavery was Biblically endorsed.
Ah, here we are... Leviticus 25:44-46 :
44 Your male and female slaves are to come from the nations around you; from them you may buy slaves.
45 You may also buy some of the temporary residents living among you and members of their clans born in your country, and they will become your property.
46 You can bequeath them to your children as inherited property and can make them slaves for life, but you must not rule over your fellow Israelites ruthlessly.
I think the Olympic records for the hundred-metre dash are down to around ten seconds. So for at least some people, speeds of ten m/s are possible.
For a Wall of Death with a ten-metre radius, you'd get an acceleration of v^2/r = 10 m/s^2, about one g. So on Earth, you could have your "wall" tilted at 45 degrees and would make a circuit every six seconds or so, and would experience about 1.4 gravities (the vector combination of the earth pulling you down at one g and your own efforts causing one g horizontally.) Which might slow you down a bit, of course; I'd certainly run slower if somebody loaded 40% of my body weight on me.
On the moon, the wall would only need be tilted about six degrees from vertical, and you'd experience about a one-g horizontal pull only (the added 1/6 gravity vertically wouldn't do much, except require the tilted wall.)
You could make the WoD slightly smaller so as not to require world-record dash speeds, of course. I'd think that at some point, you might be trying to turn around too sharply for it to work. I chose a ten-m radius above mostly to keep it simple; ten is, of course, a "physicist's dozen".
I believe you are referring to this. I first recall seeing it sometime in the 1980s.
I think (but am open to correction) that the idea is that /tmp is cleared during a (normal) shutdown, not on booting up. So if you boot up again after a crash, your files will be there; reboot normally, and they won't be.
I've not actually tested that, though (hadn't even thought about it until now). I'll check next time I get a system crash. My various Linux boxes have all cleaned /tmp sometime between (normal) shutdown and reboot. If /tmp is indeed cleared on some systems at boot time, though, I'd invert your comment a bit : a service that keeps a working file in /tmp should assume it could be gone after a reboot, and should be keeping that file someplace else if that loss would be a problem.
My FreeBSD box, on the other hand, doesn't clear /tmp automatically. I'd become accustomed to /tmp being cleared with each reboot on Linux, and had become somewhat casual about writing code that would leave files there. On the FreeBSD box, that resulted in accumulating long-since-useless files. (It really should have occurred to me, even before seeing this happen, that some machines are rebooted very infrequently, and that some people were doubtless running my code on such machines.)
Interesting point. I just Googled "best source of iron in diet". I almost always use DDG, so Google probably has less info on me than on the average bear.
I get a grid of nine images, three meat (beef, sardines, oysters) and six plants (soybeans, lentils, dandelion greens, nuts, apricots, spinach), followed by a sponsored link saying that "The best sources of iron are animal-based foods like meat and eggs", but then adding that some plant-based sources are okay too. Seems like a reasonable generic reply if you don't know much about the initial biases of the person making the search.
...or a little under a zepto-fortnight (zFn).
(I realize hyphens are not usually added after SI prefixes, but "zeptofortnight" looks like letter salad to me. If it makes the meaning clearer, I'm putting a hyphen in, no matter what the pedants say.)
Well, I've just wasted quadrillions of femtoseconds on this. Time to move on.
You nerd-sniped me. JPL provides a really good ephemeris generator (for spacecraft and natural objects) at
https://ssd.jpl.nasa.gov/horizons/app.html#/
By default, distances are given in AU.
The speed of light is 299792.458 km/s. There are 24*60*60 = 86400 seconds in a day. There are 149597870.7 km in an astronomical unit (AU).
So the distance we're looking for is (299792.458*86400/14959787.7) = 173.1446 AU, about five times further out than Pluto.
Select "Voyager 1" and start running ephems for various time frames, and you get that distance at the time given in the subject line.
(I did this thinking that there was a decent chance that I'd say "it'll reach that distance on date X, but be back within that distance at this slightly later date, then cross it for good a bit later." It's receding from the sun at about 17 km/s, but the earth orbits the sun at about 30 km/s. Right now, and for the next few months, we're catching up to it and the Earth-Voyager 1 distance is decreasing. But it only decreases between late January and late April; the overall trend is, unsurprisingly, toward greater distance.)
What you are missing is a man-in-the-middle attack on the key exchange, performed by pico-Mallory
Not missing; I was mis-remembering. You're right; this remains subject to MITM. Back to the drawing board...
Okay, Alice and Bob are just going to have to have a shared private key, imprinted on the CPU and TPM at the factory. My initial thought was that it'd be a pain for each CPU and each TPM to have a unique number built into it. However, Intel® and some other CPUs have had serial numbers burnt into them (and perhaps still do, for use with the ME?) So it may not be infeasible.
Or, I suppose you could use Diffie-Hellman only once, the first time the TPM and CPU communicate. If somebody accesses your laptop after that and inserts the Raspberry Pi/Mallory, the TPM and CPU can say : we already have a shared secret, and we aren't telling you what it is.
All of this, of course, just makes things more difficult rather than impossible to break. As has been repeatedly mentioned, if you don't have physical security, somebody can figure their way around whatever cleverness you've done. (Which isn't an excuse for making it easy to break.)
Perhaps I'm missing something here, but it seems like the usual case where Alice (=CPU) and Bob (=TPM) wish to communicate without Eve or Mallory (=Raspberry Pico) able to learn anything useful. The CPU and TPM use, say, Diffie-Hellman to get a shared private key, and the TPM sends the passphrase encrypted with that key. Eve/Mallory sees lots of data going to and fro, but nothing from which a passphrase can be practicably extracted.
As noted, there are several benefits. We test out our ability to gather tracking data quickly to figure out where and when the object is going to hit. For small objects (all we've seen so far), we can tell people when to step outside and see a bright meteor. (Those images were taken by an amateur astronomer who got the first measurements for the object after the discover.)
For a bigger object -- say, the ~17-m diameter one that hit Chelyabinsk a while back -- we can get more warning and tell people to crack open their windows. (Most of the injuries from Chelyabinsk were from shattered glass.) Unfortunately, the Chelyabinsk rock came from the direction of the sun, resulting in a grand total of zero minutes of warning. We do, at present, miss most of these objects. Though until 2008, we'd missed 100% of them.
For a still bigger object -- say, one large enough to survive going through the upper atmosphere and big enough to damage a town or city -- we get a few days or weeks of warning, and can say : crack open your windows and maybe you should just arrange to be someplace else when it hits. The time and latitude/longitude of impact will be very precisely known, to within dozens of meters and a fraction of a second.
To give due credit, ESA's Meerkat system also monitors for impacts and predicted this one. And I think the first public mention that this would be impacting was here, on the Minor Planet Mailing List, rather than from either of these services. That post was important for notifying amateur observers throughout Europe, about a dozen of whom dropped the objects they'd been observing and switched to this one. They supplied the bulk of the tracking data... in fact, looking through the list of observatories that tracked the object, I don't think any of the follow-up tracking was done by professional observers (except by Krisztián Sárneczky, the gent in Hungary who discovered it). Those amateurs are the reason we knew exactly where and when it would come in.
A big reason these small impactors matter is that sometimes, meteorites are found. We can see lots of rocks in the sky and have collected plenty on the ground, but you aren't often able to associate one with the other. Three out of four go into the water. For this one, meteorites west of Berlin have already been found. (Warning, it's a Faecebook link. I was able to look at it without a FB account, though.) I'd think if they found some this quickly, more bits will be found.
(5) At least some auditing of paper ballots ("do the paper ballots match what the machines told us?") occurs. Maybe pick a few boxes at random after the election, possibly allowing the political parties to pick some as well.
No objections to your 1 through 4, of course. But while I consider myself a skilled programmer, I wouldn't trust my own code without running basic sanity checks of this sort. Don't tell anyone, but even my code sometimes has bugs in it. (Not often, of course.)
I should note that while I thought of (5) long ago, I've since read similar proposals elsewhere, and I gather that at least some US states are considering such measures. The only downside I could see to it would be that you couldn't demagogue election fraud quite as easily.
Who would want a toaster that could last a hundred years ? Who would pay the price for such a thing ?
An interesting analysis of why modern toasters don't last as long as "old fashioned" ones did :
https://www.nytimes.com/wirecutter/blog/your-toaster-will-eventually-fail/
From that article : "...It seems that modern toasters are the kitchen equivalent of printers—everything in the category is pretty crappy."
Nice! I didn't know it would do that.
I'd say picking that date as the switchover is a minority choice, though. The astronomy code I wrote has the switchover in October 1582, when the Catholic world of that era dropped ten days. I think Turkey didn't switch until 1923.
man cal says that unless you specify a country code, ncal
tries to guess the switch date from the local environment or falls back to September 2, 1752. This was when Great Britain and her colonies switched to the Gregorian Calendar.
So if some of our fellow commentards run cal 09 1752 and say "so what?", that's why.
> HP LaserJet 6MP
Friends of ours had one. They were Mac users; many years back, Apple decided nobody would be using something that old. They offered it to me; I used it up until it finally went to Hardware Heaven a year or two ago. Truly a workhorse.
The only other bit of HP hardware I have is an HP-15C. Our local recycling center has a "gift shop" if you have stuff somebody else might use, and somebody had left a 15C there, in excellent shape. I'd never have been able to afford one when I was a pimply youth.
But come to think of it, I've never purchased HP gear. And given the issues with the current stuff, it looks unlikely that I ever will.
> Just because he says he believes doesn't mean in private that he believes.
Admittedly quite possible, and I suspect many idiotic ideas espoused by our leaders are for public consumption. For example, you hear often about Republicans praising He-Who-Must-Not-Be-Named-While-Eating in public, then privately complaining about him. But from what I've read, it would appear that Mike Johnson is a true believer.
> But isn't Speaker just two sudden deaths away from becoming POTUS?
Which means we're currently looking at the possibility of President Mike Johnson. A man who believes the universe is 6000 years old, created on 23 Oct 4004 BC at 9:00 AM Garden of Eden time, and who would not stand out, intellectually, in the fish tank of a dentist's waiting room. It's hard to imagine there's an alternative to President Elon Musk who would be even worse, but you could argue that's what we have right now.
My mind upon considering the above -- >
And here in the northeastern US, it's raining. Not sure for what event El Reg ran this quite accurate assessment of the correlation of clouds with interesting astronomical events, but it's lined up with my experiences all too well.
On 2024 April 08, the path of a total solar eclipse will pass a couple hours' drive north of me. I am not inclined to believe in long-range weather forecasts of the "it will be raining on day X four months from now". But I might make an exception here.
I'm writing this post on a laptop (Toshiba Satellite) with an RJ11 modem port and three USB ports. (Not that I've had occasion to use the former. I'm not even sure any current Linux would support it. I'm not sure what I'd use it for in 2023; it has an RJ45 port as well, and WiFi.)
Long-time Dvorak user here, since 1994. I don't think you could get a keyboard labelled in Dvorak at the time, so I learned to touch-type without looking at the keys. Even had a labelled keyboard been available, I sometimes have to use somebody else's machine with a xWERTx keyboard; I can switch their computer to Dvorak and type away happily. (Though I sometimes forget to switch it back, leading to a "why is my keyboard producing gibberish?" inquiry... fortunately, my wife and my mother, the usual inquirers, have learned how to switch back to their favored QWERTY layout.)
Another minor advantage : I was looking around for a decent second-hand ergonomic keyboard, and saw some for sale with Korean layouts. Not an obstacle if you aren't looking at the keys anyway.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
