Posts by Bill Gray 182 posts • joined 12 Aug 2014
Wondered about that myself.
echo "37.9259259*86400" | bc -l
3276799.9977600
A timer running with 100-second units would overflow a signed 16-bit int in the specified time. Dunno why you'd have a timer doing that?
I vaguely recall some other Micros~1 timer that stored (I think) milliseconds since boot time in a 32-bit unsigned integer, rolling over after 2^32/(24*60*60*1000)=49.71 days. Apparently, our friends in Redmond assumed there was no way the system would stay up that long, and one must concede they had a point.
Errmmm... if you look at the Fine Article, you'll see that this _does_ use the IEEE floating point standard for 16-bit numbers. Admittedly, if you simply leap to the assumption that Micros~1 would create its own standard, you'll usually be right. But not this time.
I'm anti-GMO when it's used (for example) to enable massive Roundup use. I'm pro-GMO when it's used (for example) in Bt-corn to enable _less_ pesticide use.
As with most technology, you gotta look carefully at specific uses. Computers enable me to read El Reg. But they also enable F__ebook.
Thank you. I've been coding in C and C++ for over 30 years. It's been rare for me to see that ordering, and when I did, I wondered why it was "reversed". But I see your point; it does make the difference between assignment and comparison clear. Only failure I see is for 'if( a == b)", where it can be a mis-assignment even when reversed... but most of the time, it'd let you catch mistakes.
At my local bank, I noticed someone depositing cash. The bills were inserted in a cash counter, which (I assume) would have no difficulty detecting serial numbers. And, of course, when dispensing cash at an ATM, the bank could know which bills were passed out to whom.
I dunno to what extent banks and other cash-scanning/dispensing businesses are taking advantage of this ability. It's very limited, in that the bank in question can't be especially confident that it'll see the same bills twice. But it does seem that if there's a way to conduct surveillance, people will do it.
Well, it also needs to understand the obligatory XKCD.
First, I'd be hard pressed to argue that states have rights and people don't. (Some can; the writers of the US Constitution were representing states, not the US as a whole.)
Second, while I agree that the original intent was a compromise of the sort you describe (a way to reassure small states that they wouldn't get crushed by big states), the actual result is that the presidency is decided by those in Pennsylvania, Ohio, and Florida. Much effort by both sides goes into those states. Small states where the outcome is unlikely to be changeable are ignored; your opinion, as a voter in an overwhelmingly blue or red state, doesn't matter.
It doesn't have _nearly_ enough mass to have a noticeable effect on us.
I write software for determining asteroid orbits from observations. _Usually_, the effects of asteroids perturbing asteroids are so small that they're lost in the noise. In some cases, if you're lucky and an asteroid is big enough, you see a noticeable perturbation on some other, usually smaller, asteroid... which is nice, because the amount of the perturbation can tell you the mass of the other (larger) asteroid.
For this to happen, you usually need the two rocks to go past each other fairly closely and slowly. There are a few hundred cases where we've been able to do this and get a reasonably decent measurement of asteroid mass. With the exception of a few spacecraft flybys (Galileo past Ida and Gaspra, for example), and a couple of tiny objects (couple meters across) where we could measure how much solar radiation pressure affected them, that's the source of everything we know about asteroid masses (and from that, asteroid density).
The rocks for which we've measured masses are usually dozens to hundreds of kilometers in diameter. For the bigger guys, the percentage errors can be quite small.
I'm trying to come up with some way you could make a plug that can't be removed without a key.
The easy solution would involve a modified faceplate, one that adds a hasp next to the outlet and a projecting loop next to the plug. Put in the plug, add a lock, and you're good to go. (Unless the cleaner brings along a screwdriver to undo the faceplate... I'll ignore that issue, and assume we just want to stop someone from casually pulling the plug.)
Ideally, I'd want a gadget suitable for adding to existing equipment and outlet : turn off equipment and unplug it, plug gadget into wall, plug device into gadget, turn key to lock it in place, turn equipment back on, and put key into pocket.
It'd be easy enough to have the gadget hold the plug in place. It's keeping the gadget locked to the outlet that poses a larger engineering challenge.
You _really_ don't see a use case?
You're old. You don't see well at night/react the way you used to. You still would like to go to your bridge club/book group/inamorata's.
Public transportation doesn't extend to where you are, or you'd have to walk a mile or two to get to it, through the snow, uphill, both ways.
You have a small child. You'd like to get the small child to her euphonium lesson, but $(DAYJOB) interferes.
You're reading a really interesting book about playing the euphonium, and your hour-long commute stopped being interesting some years ago.
(Mind you, I have serious doubts about this ever working. Something safer and more reliable than your average driver would be a low bar, but I can't see people settling for anything less than near-perfection. But it would be nice to be proven wrong.)
Last June, Ubuntu decided that the 19.10 release would drop 32-bit support. It was promptly pointed out that this would kill Wine.
https://www.theregister.co.uk/2019/06/24/steam_wine_ubuntu_32_bit/
Eventual decision (at least according to the update at the end of the Fine Article) was that some compromise would have to be made. Just killing Wine wouldn't be an option. (Which, as a person who uses Wine a fair bit, I was relieved to hear.)
As the "deadline" approaches, it could be that Apple realizes that nuking 32-bit code from orbit will cause some similar trouble. (Or maybe not. Microsoft did just that with 16-bit code a while back, and they seem to value maintaining compatibility back to the Stone Age much more highly than Apple.)
I assume we'll lose Wine on OS/X as a result of this.
If you've not given Wine another chance recently, you should consider doing so. It is by no means certain to work, especially if the code in question is buggy or uses some outré API call. But it's gradually gotten _much_ better, in my experience.
Though I can sympathize with the daunting nature of such a transfer. My mother was stuck on Windows for years because she needed to run a particular bit of payroll/accounting software for her husband's home business. Only solution was for him to retire. After he did that, Linux worked well for her. That solution is not open to everyone.
I am reasonably certain that Linus' point was that for this particular purpose, the hash needed to be fast and reasonably "random" in its output. It didn't need to be cryptographically secure.
I think some of my fellow commentards are thinking of hashing solely in terms of security (which is the use that gets most of the attention). Hashing gets use beyond that. Some hash functions (such as that used in the Linux ext3 system) are almost trivially insecure; they are for use in hash tables for indexing data. Personally, I've had cause to use a ludicrously insecure hash function in my astronomy software. I needed maximum hashing speed (the function was a performance bottleneck) and a good enough output to avoid collisions. Security was not an issue.
(I should note, though, that I'm taking Linus' word that the hash function for Git falls into this category. If so, I could easily see him saying : we've got the SHA-1 code sitting around; it works; we don't care if collisions can be engineered; let's use it.)
Don't see why not. I'm reminded of the Invisible Pink Unicorn (blessed be Her Hooves), which reflects the union of faith and reason. We know through faith that She's pink, but can demonstrate through reason that She's invisible (i.e., we can't see Her.)
I'm sure suitably faithful Apple users would be confident that the keyboard was shiny, even if they couldn't see it.
As a former RSI sufferer, I wonder. (Switching from hunt/peck QWERTY on an 'ordinary' keyboard to touch-typing Dvorak on a split keyboard made the problem go away, though I've no idea which bit did the trick... took me about a month to get back to speed; in another month, I was considerably faster than I'd been to start.)
I just tried "touch-typing" on the table in front of me. Obviously, I don't have to hit as hard as I would on my mechanical keyboard. I could imagine a camera looking at my fingers and figuring out what I was 'typing'. Your mileage may indeed vary, the plural of anecdote is not data, and I've not tried it for years on end. But I _think_ it might actually be gentler on my wrists.
A surgeon, a civil engineer, and a politician were arguing about who had the oldest profession. The surgeon said, "Eve was created from a rib removed from Adam, which surely makes surgery the oldest profession."
The civil engineer said, "Yeah, but before that, the universe was created out of chaos and darkness. Sounds like a civil engineering job to me."
The politician said, "But who created the chaos and darkness?"
"...My phone often has a skew of rather more than that on its clock and yet can get a decent satellite only location fix via GPS"
Light moves at about 300000 km/s. One millisecond corresponds to about 300 km, so I can guarantee you that the GPS circuitry in your phone has the time nailed down to better than a microsecond (300 meters). But I do know what you mean. I've seen devices where the time displayed clearly wasn't coming from the GPS.
On at least one older, stand-alone GPS unit, you could turn it on and watch the clock as it searched around for satellites. When it got a position fix, the clock would jump by a few seconds. It had a somewhat crummy quartz clock, just good enough to figure out which satellites might be visible. Once it could "see" four satellites, it had four equations and could solve for four parameters (x, y, z spatial coordinates and delta-T clock error). Then it would adjust the clock accordingly. (Four satellites are enough -- or three, plus a clock so you can set delta-T=0 -- but additional satellites do help you to reduce errors and give you some redundancy when you lose a satellite or two behind a building.)
I'm similarly biased toward plain ol' while loops. However, it leads to both an extra check _and_ a seemingly pointless initialization. For example,
int i = 33;
bool solution_found = false;
while( !solution_found && i >= 33)
...
as compared to
int i;
bool solution_found;
do
....
while( !solution_found && i >= 33);
Not a huge difference, I concede. But in either case, some ugliness creeps into your code.
"But of course it wouldn’t be a politician interview if there wasn’t an enormous dose of hypocrisy and irony and in this case it’s the fact that Biden voted for Section 230 in 1995. It passed the Senate 81-18."
In 1995, I'd have leaned in favor of it as well. In 2019, with a very different situation and considerably more knowledge of the consequences, I'd at least lean against it.
Someone famous (don't remember who) said, when accused of "hypocrisy" for changing his mind, something vaguely resembling the following :
"When the facts change (or my understanding/knowledge of the facts changes), I change my mind. What do you do, sir?"
We do have New Horizons going into interstellar space. A rough extrapolation puts it as far from the sun as Voyager 2 currently is sometime around 2045. Dunno if it's headed in the "wake" direction (and therefore will have to go _really_ far to emerge) or more in the "forward" direction (and therefore wouldn't have to go as far.)
We also have Pioneers 10 and 11, but lost contact with both about fifteen years ago, as they got further away and their Pu-238 decayed. Maybe we just build a bigger radio telescope, suitable for regaining contact? (With the benefit that we can find other things to do with such a telescope.)
You're wrong. There is no such thing as gravity; it's just G_d pushing things down.
(I am in awe of this article... the markings on the whiteboard behind the evangelical "physicist"... the reasoning that because we don't fully understand gravity -- which is correct -- it must be God doing everything... definitely one of The Onion's masterpieces.)
Long ago, I read that in 1895, there were two cars in the state of Ohio. They collided. (Turns out to be almost certainly an urban legend, unfortunately.)
You are correct in thinking that the Roadster is definitely in an elliptical orbit around the sun (perihelion is just inside the earth's orbit, apohelion just outside the orbit of Mars). We have a pretty good idea as to where it is and where it's going, mostly because of amateur astronomers taking images as it went into Outer Darkness and measuring its position. (NASA, ESA, etc. are usually not very interested in heliocentric objects that aren't active payloads.)
I assume we'll someday launch a second car into orbit, and the Roadster will collide with that instead.
..."Its gravity won't be enough to attract anything with enough speed to make an impact..."
Doesn't matter much. Most of the energy of an impact is due to the difference between your orbit and that of the impactor. And no, orbits are not all _that_ similar for varying main belt objects; they usually go past each other at a few kilometers a second.
"...Anything moving fast enough to make much of an impact crater would be more likely to kick it out of its orbit or destroy it completely."
Again, no. Hygeia is about 430 km across. It'd take a big rock to break it into bits, even at a kilometer or two a second. For every big rock like that, you'd have plenty of smaller ones, and they'd make impact craters.
Hygiea is only slightly further out in the main asteroid belt than Ceres or Vesta. Those have plenty of craters. There's no immediate reason to think this wouldn't have a similar level of cratering.
I revised some code a few months back to handle years beyond the range of +/-231 years. It should now be good for about 1016 years, safely after all red dwarfs have cooled, though not long enough to work after proton decay and black hole evaporation dismantles the universe.
(I'd like to claim that this was to set a record in planning ahead, but it's not. The code in question is used for astronomy, and the universe is more than 231 years old and will be around for much more than another 231 years. The "usual" date libraries that either don't work before the years 1582 (Gregorian switchover), 1 (no zero/negative years), or -4712 (start of the Julian Day system), and/or fail after 2099 or 2999 or 9999, are not suitable for the purpose.)
I found, and have used, the script at the end of this post to download all posts from the groups I manage. (Fortunately, we'd used them just to swap messages; we didn't have any significant files uploaded to Yahoo!.) The posts are provided as HTML spaghetti; I am working on code to convert the posts to a usable form. As you'll see, it's a work in progress... but the important thing is to grab your data before Yahoo! deletes it "to serve you better" / "to increase shareholder value" / "to improve the customer experience". The script will grab that data for you.
Many people are moving to groups.io. I'm using GNU Mailman on my own server. groups.io appears to be a decent place at present, but then again, Yahoo! was decent for some time.
:=)
"...Good code is written once and read many times..."
That took me a while to figure out. I have quite a bit of code that I wrote starting in 1992, and I wasn't really thinking about the possibility that I might be looking at it 27 years later, wondering what the %&!# my younger self was trying to do. Eventually, I came around to this point of view (written concerning a clever, but impenetrable algorithm):
https://github.com/Bill-Gray/lunar/blob/master/date.cpp#L103
/* Personally, I like to be able to look at a chunk of code and see what it means. It should resemble the Reformation view of the Bible: anyone can read it and witness the truth thereof. */
I'd be torn about this. (Though I don't really have a dog in the fight. I've programmed in C daily for decades, but do virtually nothing in Python.)
Most C and C++ compilers (that I've tried, at any rate) will give you a warning in almost all cases where you use = in a place where == ought to have been used. But you have to have compiler warnings turned on (I'm _amazed_ at how many people don't do this, but... they don't.)
Much of my code is open source, and may be read/used by people with a range of coding skills and C knowledge. I avoid assignments within conditionals in any code that other people will see, and rarely use it even in code that will never leave my machine. It's not that an assignment within a conditional is always terrible, but it _usually_ indicates that the bit of code in question should be rewritten and made clearer. Certainly in the instance you give, where I would argue that the following is easier to read:
x = SomeFunc( );
if( x > 0) { /* use x */}
Please use multiple machines with a range of OSes and compilers.
I write software for determining asteroid orbits from observations, and their probability of impact with the earth and where they will hit. I compile and run the code on Linux, FreeBSD, and Windows. I use GCC, clang, MinGW, and Microsoft C/C++, with full warnings on each. If I get different answers, something is wrong and needs to be investigated.
You may have heard that "a man with one watch knows what time it is; a man with two watches never knows what time it is." More realistically, the man with one watch is certain what time it is, but probably wrong.
If you tell me you did scientific research and got a result, and did as little checking of that result as possible for fear you'd get a different answer, my trust in your result will be nearly zero.
Kinda surprised nobody's pointed this out : Moore's Law posits a _doubling_ of computing power every 18 months. You've got it as a _quadrupling_; it's 2^25, not 4^25. You also have it as 25 quadruplings times nothing in particular, rather than 25 quadruplings starting from four days.
So we really ought to be thinking that 40 years ago, it would have taken about 4(2^25) days to crack this password, or about 370,000 years. Still a long time, I grant you. But not 200,000 times the age of the universe.
52! = 8.06e+67 (roughly)
We have 10e+9 * 1e+9 * 200e+9 * 500e+9 = 1e+42 people on the job
Each checks a million a second, so we're going through 1e+48 combos/second
It ought to take about 8.06e+19 seconds
There are about pi * 1e+7 seconds in a year, so about 2.56e+12 years
The universe is about 13.8 billion years old, so we'd be about 0.5% done.
I started this out thinking I might show you were wrong. Obviously, we're _way_ behind on the job... time to start populating the universe, building lots of playing card factories, and practicing our shuffling skills.
For machines with paper records, it standard practice to select 1% of machines (or a statistically significant number, anyway) _after the election_ for a by-hand recount, to be compared to the machine results. If it were me doing it, I'd make it some percentage at random and give each major party the right to add a few machines to those that were checked.
I don't think the objections to such a procedure would come so much from the politicians as they would from the manufacturers of the machines.
1729 = 12^3+1^3 = 10^3+9^3, making 1729 the first "taxicab number."
https://en.wikipedia.org/wiki/Taxicab_number
From the above :
The name is derived from a conversation in about 1919 involving mathematicians G. H. Hardy and Srinivasa Ramanujan. As told by Hardy:
“I remember once going to see him [Ramanujan] when he was lying ill at Putney. I had ridden in taxi-cab No. 1729, and remarked that the number seemed to be rather a dull one, and that I hoped it was not an unfavourable omen. 'No,' he replied, 'it is a very interesting number; it is the smallest number expressible as the sum of two [positive] cubes in two different ways.'"
Somebody (don't remember who) once said of Ramanujan that it seemed as if every integer was a personal friend of his. So it's not too surprising that Ramanujan noticed this right away.
Unfortunately, Ramanujan died the next year, so the "favourable omen" bit didn't pan out.
Hmmm... Maybe I'm missing something, but it sounds to me as if you're addressing a different set of issues.
My thought is as follows. For randomsite.com, my password is my first pet's maiden name, ⅔שלфщ®куè (I used to pick some odd names for my pets). Within the browser, this is salted/hashed and we get, say, DEADBEEF5318008, all ASCII hex digits. That's what gets passed to randomsite.com. They don't know how long my password is, or if it has non-ASCII characters.
Because I can see the script, I can verify that randomsite.com doesn't know my pet's name; they just know that when salted/hashed, it's DEADBEEF5318008. They really ought to salt/hash it, store the result, and forget about DEADBEEF5318008. But I may not trust them. Or they may screw up.
So then they get hacked. World+dog promptly checks my banking and e-mail and other accounts to see if I used that password elsewhere. Which, of course, I did (doesn't everybody?) But -- because randomsite.com never knew my real password and only saw DEADBEEF5318008, and nobody else knows about my beloved pet ⅔שלфщ®куè -- they're out of luck.
They can access my randomsite.org account, though. Unless randomsite.com isn't run by bozos after all, and _did_ take the DEADBEEF5318008 I sent them and salted/hashed it.
But this scheme only protects against password re-use (and allows me to use a non-ASCII password). randomsite.com still ought to use https and otherwise follow best practices.
You're partly right -- I'd like to be able to enter a password in Russian, for example, but would have to accept that I don't have a way to enter Russian on my phone. For some sites, I can accept that limitation, because I only access them from a desktop or laptop where swapped keyboard layouts are a hotkey away.
The cases I'm thinking of, though, are more along the lines of not letting me enter spaces, quotation marks, or commas. To me, those restrictions smell of storing passwords in plain text, not of a well-intentioned effort to keep me from locking myself out of access from my phone (or Tektronix terminal).
Whenever I see a 20-character upper limit, I assume passwords are stored in plain text. I could see an upper limit of, say, 500 characters to avoid DoS attacks or efforts to overflow buffers. But those smaller limits look suspiciously as if somebody wanted the unhashed password to fit into their database.
Am I wrong? Is there actually a good reason to insist on a lowish upper limit?
For that matter, I make a similar assumption when I'm told my password can't contain spaces (or commas). That suggests to me that their database would interpret my password as two or more fields. A password should be able to hold any Unicode text; after all, once hashed, it's a string of hex digits anyway.
My preference would be that my password be salted and hashed _in the browser_. This doesn't remove the need to use https or for salting/hashing to occur at the server end, but it does mean that I have good reason to think that the site I'm communicating with never sees my unhashed password and cannot, no matter how badly the security is botched, leak my unhashed password. (Which provides them with a degree of security as well, and an excellent defense if accused of leaking passwords : "It wasn't us what done it; we couldn't have done it had we wanted to.")
It also, of course, means that if I wanted a gigabyte-long password, it'd be fine. It'll just get salted and hashed and the same number of bytes get sent to the server.
Um. Unfortunately, good points; in fact, I wonder if a thief's instinctive response to the siren would be to not simply drop the laptop, but to fling it away as hard as possible.
But the general idea of treatting a (specific) disconnected USB device as an indicator of theft still appeals to me. Question is, what should the laptop do in such a case?
Perhaps, instead of using a siren, the computer just encrypts files and turns on webcam and microphone. (And otherwise behaves, as much as possible, "normally" so that it can do as much encryption and spying on the thief as possible.)
Logging the SSIDs of passing WiFi sites might also help. I suspect that in a city such as San Francisco, if you know what routers you've passed, you know where you are.
"I have a bicycle that is worth about £10."
I read about somebody who wanted to get rid of an old refrigerator and put it on the lawn with a "Free" sign. It sat there for a week.
So she changed the sign to read "Fridge, $50, inquire within." It was gone the next day.
An interesting thought. Seems to me no special device is needed; simply plug in any bog-standard USB device (camera, mouse, storage, etc., ideally on a cable) and have something set up to complain loudly if that device is removed. The laptop should show a dialog : "Enter 'safe' code or reattach device to turn off siren".
Some flexibility should be allowed in what happens if the code isn't entered/device isn't reattached in X seconds, but wiping/encrypting files might be a good option. Perhaps taking a few images with the Webcam and e-mailing them to a predefined address.
The "siren" should also be customizable. I might have mine shriek, "I'm a stolen laptop! Put me down gently and walk away, or I'll explode!"
Note to downvoters : I'm not totally sure of this, but I don't think I knew about Vauxhall before becoming an El Reg reader (I'm a Yank). Similarly, I'm reasonably certain I'd not encountered words such as Septic (in the sense used to refer to me and my compatriots), sprog, todger, or any of several dozen other UK phases prior to reading these pages.
I have, of course, noticed corresponding (albeit generally smaller) gaps in knowledge of US culture/language among the UK commentardiat.
(If the downvotes are due to Opel being a German automaker rather than British, I can't argue with that.)
Yeah, I could have been clearer there.
The actual risk is either zero or 100%. The rock hits us or it doesn't. Our _estimate_ of the risk depends on what we know at any given time. We've accounted for 90% of the one-kilometer rocks and know they won't hit us. In the course of that, we've gotten a more accurate idea of how many one-km rocks are in our neighborhood, and it's not as many as we'd expected when we started looking.
Put those two together, and our estimate of the risk has dropped a little more than tenfold. The actual risk, as you suggest, is either zero or certainty. We won't really know until we wait and see what hits us (or, most likely, doesn't hit us).
A good point. The US, at least, has decent detection systems for such things. Nuclear explosions have a distinctive "double flash" : you see the explosion, it's briefly shrouded in debris, then you get a lot of light over a longer time. From the viewpoint of satellites, rocks hitting us don't look much like nuclear explosions; the US, at least, is unlikely to launch due to this particular sort of accident (no comment on what other mistakes might cause a launch).
However, I've no idea what the rest of the world has for such systems, and could imagine a rock hitting over Pakistan, India, Israel, etc. leading to a "whoops" moment.
I'd be reasonably, but not totally, confident that we've got the extinction-level ones. With 90% of the kilometer-sized ones found, the estimated risk from those is 10% of what it would have been circa 1995, when we started getting serious about surveying. (Actually lower than that; our estimate in 1995 of just how many one-km rocks exist in near-earth orbits turned out to be high.)
We still have something to worry about for the smaller, city- or nation-obliterating objects. I should note that it's not a risk up there with climate change, nuclear war, or runaway pandemics. Nor is it being treated as such. The number of people working in this area is not huge. It gets (and, in my opinion, deserves) the level of attention you'd give to a low-probability, high-damage risk. Not to mention that there's considerable scientific value in studying these objects.
For larger objects, the remaining risk is mostly from objects that have done a good job of hiding from our telescopes over the last twenty years : remote ("we could have had a good look at it in 1994, but it's got a 25-year orbital period") or infrequent ("much of its orbit is inside ours, where we gotta get pretty lucky to see it on one of the infrequent times it's near us.") We do find such objects every now and then. Not very often... which is why the risk from them isn't all that great.
And you're right to discount `Oumuamua and similar interstellar objects. We've found a grand total of one. I suspect we may have missed others; we have an observational bias toward slower objects that are part of the solar system. But even allowing a large margin of error for that, interstellar objects are the least of our problems.
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2020