Gwynne Shotwell
Appears to be the one making SpaceX a success, reining in silly ideas from from whats-his-name. But she is still the person who talked openly about using Starship as a vehicle for terrestrial commuters - has she recanted on that?
5493 publicly visible posts • joined 9 Nov 2021
> nuclear engines that have NO air pollution
Air-breathing to save lifting reaction mass? Taking in atmosphere, heating it up, spitting it out the backend as NOx...
IIRC it was Arthur C. Clarke (in one of his non-fiction works) had a description of a nuclear-powered aircraft being used as a first-stage (shades of Virgin Galactic) which you would spot in the sky by its lovely red/brown trail.
> It's an impressive number, but also a finite one.
It is also one that changes *all* the time, unlike current LLMs.
In your early life, you were pruning connections/weightings to get rid of the junk, in your prime you were absorbing new material faster than ever and even in your final days you'll be learning new behaviours, even if that is just how to shuffle slowly to ease the aches in your bones.
And all of those updates occur without shutting down and restarting the learning process from scratch again.
> leak the source code to a rival car company
Was that (a) "leak the Tesla code and send it to a rival of Tesla" or (b) "leak the code of a rival and send it to Tesla"?
> and become 'somehow' extremely rich shortly afterward
In case (a) - well, if the rival really likes a good laugh, they might pay well.
https://youtube.com/watch?v=nsb2XBAIWyA
OTOH being able to look back over my order history is quite useful: ah, I was right, I *did* order one of those doodads 6 years ago, but it was sent to Bert directly for his birthday. And I did buy that book and it was sent to my current address, not imagining it, so worth carrying on looking to see where it got buried.
So how much of the order data is there absolutely "no reason at all to keep"?
Forced arbitration clauses - not something you ever want to find[1] in your contracts, any contract (insurance, employment, ...)
[1] which is why the paperwork is carefully worded to obscure the clauses and hide the consequences from you: it is a kindness.
Time was, you could only make teeny tiny models that fit within the available RAM, not these humungous beasts. Which meant that, when let into the big wide world, dealing outside of the training set the cracks would show up much faster and be more obvious to everyone. Although they were a lot quicker to train (at the easy end of exponential data crunching versus linear Moore's Law) so you caould chuck 'em out faster.
Go back to the old automated-trading scams (not that anyone ever actually did this, no, nope, on my life guv): train up (teeny) models on a stock market feed. Make a fair few of these, with random variations (number of nodes, different data subsets) so that they don't all end up identical but they all re-create the historical data pretty well. Take out a great big ad stating how your amazing system managed to track the market so far (well, duh) and promise Great Riches to anyone buying it to "predict" how the markets will act tomorrow. You can even keep adding to the ad copy "certified satisfied customer reports" from purchasers who "struck gold this very week"!
Of course, everyone got a "customised model", most of the predictions were effectively random (and it has been shown more than once that random stock picking is at least as good as most pundits and traders...) and only the "big wins" are ever glorified in the press (who can be trusted to take on the burden of bolstering your ad copy). After a short time, the models are so far out of their depth that anyone can see that they are generating gibberish and the customers quietly feed their copies into the shredder (one of the great advantages of using floppy discs and CDs when buying software, you at least physical revenge). You've quietly folded your company (or, better yet, flogged the whole thing to an even wider boy - sorry, I mean "a respected trading company") and trotted back to Peckham.
But now it has all gone horribly wrong.
- the costs of the models are obscene, with the obvious repercussions (like face-saving: when you call out the quality of the goods, Rodders will look nervous and Del will give you the gab, but the boys playing with this much dosh have got nice suits with strange bulges; metaphorically, of course).
- the cracks start off tiny, compared to the size of the model and the amount of stuff it can regurgitate, so they are easily brushed off (that 10-line routine forgot to declare "loopCount", you fixed it without even thinking, almost out of habit)
- there are only a few models which everyone is playing with, so as the cracks propagate no-one will be spared from falling into the Underworld of Nightmares.
- the more people get themselves invested into something big and shiny, the less able they are to give it up. And they can't even get catharsis from the shredder (although putting one end of the Ethernet cable in might be fun, it'll still wreak havoc on anyone in the vicinity).
> So it should be with training AIs.
Well, yes - and then we'd be getting back to "actual" AIs, with internal models that are properly explained/explanatory. Expert Systems, purely as an example, can have their rule set modified piecemeal, without having to start the whole process again.
But these massive nets being sold as "AI" - there is no way to point to any of the numbers in the model and say "we can tweak that to get this result", or "removing this and adding that to the training set will change this set of numbers, and nothing else" so no piecemeal updates for you.
If a desire to fool the journals leads to these models being able to generate accurate citations then that could hopefully be added to Github's Copilot, which would fill the gaping hole of lack of attribution for the code it regurgitates.
Sadly, this won't happen, because the goal of the LLMs would be to generate citations that just *look* right but aren't necessarily accurate[1], the same as the rest of the text.
[1] Bloggs A., Chandra P. et al, 1981, p12 - 17.
Except (as already pointed out) with plain old files in /etc you can do things like version control - etckeeper for example.
Then you can check the history trivially (ok, what changed *this* time?), add comments when you actually know why and what made a change, so on ans so forth.
All with the same VC tools you know and love.
> In fact, it's arguably easier to clean up a transactional database because it "knows" who made what change when.
Ok, leaving aside the "when FAT was all that available" discussion and looking at the here and now: can you point me at the place I can find the transaction list for the Registry that'll let me see it knows "who made what change when"?
> It was needed because the only other option was FAT. I've developing for Windows since before the registry existed
None of your examples relate to the situation when the Registry was created, back in Windows 3 days when, as you pointed out, FAT was all that was available.
By the time we had a multiuser OS, with preemptive multitasking, we also had NTFS which provides the access control, file locking etc that FAT lacks.
> It was created because COM and OLE require a central repository with those features, and FAT cannot do that.
OLE needed a central repository - but, again, at the time FAT was the only filesystem available, said repository didn't require the extra features.
64 bit DLLs? When FAT was the only option?
> The registry is the Windows equivalent of a filesystem designed for the /etc tree.
Funny, I don't see anything inside /etc that needs a special kind of file system. Care to give us an example of what you are referring to? There are loads of soft and/or hard links under /etc but the Registry doesn't provide any mechanism to duplicate those (most certainly not in the days when the Registry was invented)
> It was needed because the only other option was FAT.
How does the Registry do anything there that FAT can't? Well, aside from having keys that are random hex strings way longer than 8.3?
Were you thinking of the way that volatile values within the Registry change to reflect what is going on in the system, like how loaded it is? But that would be the equivalent of the /proc filesystem - 'cos Linux keeps things like that separate from config data - and those values weren't in the first Registry either.
Or were you thinking of the way you're supposed to keep volatile program settings, like the last window positions or the last ten files opened, in your app's portion of the Registry? Isn't that the sort of thing you'd have in the User's home directory?
So far, we've got the Registry being /etc, /proc, ~/.* and I'm sure others can point out what I've missed (some stuff that belongs under /var in all likelihood). Rather a mess.
> Created to appease rights holders and integrate DRM into Windows
Not really.
The Registry came about because object linking and embedding (OLE) *needs* to have a central repository: if you've embedded a Visio image inside a Word document then Word has to know where to find Visio and how to invoke it in order to let you edit the diagram in situ. Forcing the use of an API to add keys for new OLE components was sensible - you just know that without it every third-party component would just copy its own file over, instead of appending their settings to a global file.
The rot started in immediately, when someone decided that INI files needed to be got rid off (presumably because you can write comments in a plain text INI file and doing that just made it all too easy for the User to understand).
Then it became possible to really complexify[1] things up: along comes NT and once you really have a multi-user OS where "logging in" does actually do something, you can't just treat it sensibly and store it in a directory under the User's home directory, because it has syatem-wide as well as personal INI settings. So now we get Registry Hives (so-called because of the unbearable itching feeling you get in the brain from trying to follow this mess). Ha ha, you thought you could back up all your config by saving just one file! Don't dream of restoring!
And look, we can even subvert the entire idea of having it be just a repository of (fairly stable) config items by putting in "active" data! Want to profile your system? Just read these Registry values! What, you thought you could dump the Registry, run that installer, dump again and use the diff to find out what keys the installer changed? Oh, you silly naive User, we'll never tell you what keys do what.
[1] What, complexify doesn't get underlined in red? It is in the dictionary? Good grief.
> it's as if people don't understand that building something with no design for expansion then patching each new feature on in the way that takes the least amount of time has any downsides. They don't seem to think that there's anything bad about the fact that there are three systems for doing the same thing, all of which work in different ways, have different interfaces, and are missing a few features that another one has.
Odd, I thought the discussion about Windows Registry was going on in a different thread.
It would be massive overkill to use something like a Dragon to land this material, especially given that the capsule would have to catch the payload and stow it before the landing (although that might be the sort of thing done for the first one or two returns, to give them a good chance of returning intact for analysis, excess costs being rolled into R&D).
Depending upon the materials being returned, they won't need the mollycoddling a Dragon capsule can provide - plenty of iron reaches lands as meteorites and is still extremely cold from space on the inside (ok, it had a looong time to cool, which this ore won't have). It will need some ablative material (don't want to waste the good stuff) and some braking/steering but still nothing terribly precise: long term, let piles of small payloads whack into the ground across a broad area of desert. Go out once a month with your tracking data to collect them. I'm thinking that actual landing velocity might be chosen based more on whether the landing assist package could be reused if treated carefully or whether it wasn't worth the effort!
By the time an actual return is ready to be tried, we will have had more practice at things like skipping across the atmosphere to reduce speed and fly with minimal control surfaces towards the landing zone. Maybe then something weirdly simple might be dreamt up and made to work for the rest of the braking & landing.
Projector screens are retroreflective. Nip to the local fleapit to borrow one of those for protection and you can camouflage yourself as a drive-in cinema.
For bonus points, show the enemy "Primer" and take advantage of the confusion as they try to figure out what is actually going on in that movie: https://xkcd.com/657/
Huh? That is a lousy assumption to make, no matter *what* hash you use to index a cache, you can *never* assume it is collision-free!
Trivially, every hash will generate collisions, it is inevitable: reducing every single input to a fixed-size hash of k bits means that as soon as the world has processed 2^k + 1 inputs there *must* have been at least one collision. The point at which there is a 50% chance of hitting a collision is a far, far smaller number than 2^k
2^k may be a huge number, but it is not a guarantee that no collisions can occur. So that cache was going to break for someone, somewhere, even without any malicious intent. It was just a low probability that it would be *your* system that was impacted today.
Certainly hope that no other code is using a cryptographic hash as an index and assuming that the results are unique <cough>
Remember, breaking a hash, the way MD5 was broken, just means that the task of *finding* a collision with a specific target is a lot easier (trivial, even); it doesn't mean that such collisions are impossible.
> Theremin as the primary control interface.
That would help with the whole issue of EVs needing to make noises to avoid creeping up on pedestrians. But what would you play to get the thing started? "Good Vibrations"? "Please Go Home" to initiate auto-park?
(Bit late to the story, but...)
> I think they were originally billed as Smalltalk machines
PERQ = Pascal Engine Running Quickly
They were built from the Pascal engine hardware derived from work on UCSD Pascal (which Apple ][ users may be familiar with) and its p-code.
I worked on one for a year in the early 80's and everything we had on it was in Pascal. Pretty sure that included the OS (may have been Unixy but not actually Unix).
The comic book presents a muddled situation and, if the copyright is upheld (which my guess says it will be) it is going to be gloriously misreported all over the place.
You can, IIRC, claim a copyright for a collection of non-copyrightable items taken as a whole, such as 'phone directory: the names and numbers are just basic facts, free for anyone to use and publish, but the way they are expressed can be copyrighted. On that basis, the comic as a whole is easily copyrightable, as a certain collection of images organised in a certain fashion (namely, to tell the specific story). It would not surprise me if a decision was made on those grounds alone, simply so that the USCO examiner can put their tick on it and not have to spend any more effort on deciding if the items being collected are copyrightable or not; let the next guy worry about that.
But when (if) copyright is granted just on that simple basis, it will be bound to be reported that the images from the AI were declared copyrightable. Lots of bushes will then be beaten up by people who have grabbed the wrong end of stick.
But at least you put some personal effort into it, queuing the night away!
And a ten tickets per person limit at least meant the old-time big-money touts had to employ a few warm bodies, not just keep switching IPs on a few VMs to fool the frontend into letting them get another bite.
>> 4 * 41616 / 65536 being close enough to 2.54
>Why not 2601/1024? Or 254/100 ? Or 127/50 ?
Wild guess - divide by 65536 is shift by two bytes or, if the precision is good enough, drop least two bytes to go from four byte intermediate value to two byte stored value without bothering with any actual arithmetic?
Or something else along those lines, choosing the maths that works best with the machinery being used.
Big Clive has talked about picking up discarded single-use e-fags from the streets of Glasgow and harvesting the rechargeable lithium batteries from them.
Perfectly rechargeable lithium batteries, in single-use products!
https://m.youtube.com/watch?v=PsJMj7FtroY
Time to point out that there is no such thing as someone speaking without an accent?
Obviously, they meant there isn't much of a *range* of accents, but now I'm wondering which one is the dominant one in the data set. What is an easy accent to capture a lot of to make a public data set; they mention speaking on 'phones and it'll be one that is easy to record over any background noise...
It's Essex girls on busses, isn't it.
First of all, your old kit can still run using the older kernels etc, so there is still plenty of scope for doing useful work - although what one person considers useful may not suit another, of course.
And there are OSes that take pride in supporting as wide a range of kit as possible (NetBSD for one).
Otherwise, to keep older hardware from being dropped, you can consider volunteering your time and working kit to be used in the regression tests. Or getting together with other people who have the same old hardware and taking a group effort of it. Or just handing over a suitable pile of moolah to convince someone else to take on the challenge.
After all, my understanding is that the basic problem is the simple one of too many hardware variants and too few testers and developers to give all of those variants the attention they would need to support the latest kernel changes; changes that are required to actually make use of the current hardware.
Not only does the new hardware support have to be added but at worst the changes have to be benign on older CPUs, at best simulated in extra software written for the old boxes. Time and energy (aka "money") then has to be devoted to keeping that extra module tested and in step with ongoing progress, especially as once the clever h/w feature is in place, more and more of the other "unrelated" areas of code will start to rely on it, and all its corner cases, putting more strain on the simulation module or breaking because the "benign" ignoring of the feature is no longer good enough.
It takes more than just automated regression testing: they need the working kit and enough of it, the ability to fix regressions (see above paragraph), time and money to keep it going (where does extra kit live, on whose mains?).
> graphic / product design team to be specifying the look and feel, then devs code to the spec
Surely the product design team use a "no code required" UI generator that lets them test all of their UI screens and just spits out a massive lump of code filled with comments /* to-do : fill in button press action */ Any fool of a dev can replace with those with the obvious database calls, after all, we've done all the tricky creative stuff for you already!