> It's a bit surprising to see the former used by an American author in an American publication, however.
Strange things happen to American writers who read lots of Russian novels translated by Brits.
1,811 karma · joined September 9, 2013
Oakland, California
https://kemitchell.com
Strange things happen to American writers who read lots of Russian novels translated by Brits.
I marked this story to follow up on when it broke, because it interested me.
I'm no Musk fan, but I did find his telling of this story credible: Starlink was initially disabled in Crimea due to sanctions, the Ukrainian uncrewed surface vehicle team assumed coverage would be available all the way to their target, and Musk declined to extend coverage when they asked at the last minute, in the context of a specific, planned military operation. I happen to be a lawyer familiar with those sanctions---and how businesses tend to address them---but you could cross-reference stories about GitHub and others freezing accounts of people logging in from Crimean IPs for a sense.
Either way, I'd be careful with words here. I don't recall any reports of Starlink being shut down for Ukraine or Ukrainian forces overall. There was another news arc some time before about Musk insisting the government pick up the tab for continued service. But as far as I know that never resulted in any major service disruption. I vaguely recall it's now on Department of Defense contract, but you'd want to check that.
Transliterations make it easy to confuse the difference between the grammatical endings of русский (singular, masculine adjective used as singular noun) and русские (plural adjective used as plural noun). The end of English "Russkie" is pronounced more like the end of "русский", while the plural "русские" would be something like RUSS-key-yay in English, ROOS-key-yay in Russian.
The general rule for making singulars plural in English is adding -s. The general rule for Russian nominative-case adjectives is adding -ые or -ие. Granted, native Russian speakers often speed through and slur unstressed grammatical endings, so the difference isn't always discernible in speech.
The important point to get across is that pipes let us build bigger commands from the commands we already know. If needed, you can back up later to teach patterns like `find [...] -exec`, `find [...] -print0 | xargs -0 [...]`, `find [...] | while read -r file; do [...] done` and so on.
There are all kinds of prerequisites to creating files with unusual names. Those barriers tend to mean beginners won't run into file name processing edge cases for a while. The exception will be files they download from the Internet. But the complexity there will usually be quote and non-ASCII Unicode characters, not newlines or other control codes.
In teaching, the one filename complexity I would try to get ahead of, preventively, is spaces. There was a time, way back when, when newbies seemed to expect to stick with short, simple filenames. These days they the people I've helped tended to be used to using spaces in file names in Finder and Explorer for office or school work.
I'd be interested to see what kind of non-discrimination provision was removed. A rule against discriminating against people for exercising their privacy rights, like we see in the California Consumer Privacy Act, GDPR, &c.? Or a more general, civil rights-style prohibition, perhaps incorporating a list of protected classes?
They mention the new draft could be weaker than state laws it would preempt. I take it that's most likely a reference to California law. But it comes after discussion of a loophole they see for on-device data, not the part of about non-discrimination.
It makes sense for a civil rights organization to want strong nondiscrimination language in a federal privacy bill. But I'm not sure we've seen those bundled in one law and passed before. We have with AI-specific legislation. If the APRA is turning into more of an Omnibus Big Tech Bad Behavior bill, AI regs included, that might make political sense.
In my own experience, human forecasters and decision-makers tend to be much easier to hold accountable for bad forecasts and decisions. At a minimum, they stake their reputations, just by putting their names to their actions. With algorithms, by contrast, there's often no visible sign of who created them or decided to use them. There's often no effective process for review, correction, or redress at all.
The fact that high-volume, low-risk decisions tend to get automated more often may partly explain this. But it may also partly explain general attitudes toward algorithms, as a consequence.
I don't think it's somehow also Philip's burden to find or vet or train a successor. The code is out there. His license terms are unobjectionable.
If and when Philip stops work, let someone else who cares pick it up. Perhaps under new and different names. The links between the names Philip chose and Philip himself as the person behind the work will have been broken, anyway.
Follow-on forks won't take away from Philip's legacy one bit. They might even help raise attention that new groups or individuals worthy of gratitude have stepped up.
Giving a bunch of projects $300 a month in credits for six months is still far more than nearly any company does.
I wonder if they had projects legitimately consuming more than $300 a month of their services.
It's hard to tell what, exactly, the position on "open source AI" was. It's presented here in glittering generalities. Given the many conversations I've had on-theme with not-public-tech-co people, I don't think it's fair to say all of "little tech" has one view or position, when you really get down to details. I rather doubt the whole YC-o-Verse sees it all one way, either, given its burgeoning size.
More broadly, I'd expect positioning off as "little tech" to flop. Policy players know how to follow the money. They know "Big Tech" brings the money that buys startups—they've read about it in exec summaries of the committee reports. They're also plenty aware that startups get founded by, and recruit from, a lot of the same pools of people. They've been lobbied by various policy groups speaking for smaller tech companies, often funded by the bigger tech companies, for years. If they dig just a little bit, they'll see the barriers to entry, and resulting big-co dependencies, for small-cos doing AI work.
There's bipartisan support for "going after Big Tech" competition-wise. I don't think the pols need a tech-co splinter group as reinforcement there. Unless and until IPO becomes the main path of successful ascent again—perpetually private isn't popular—I don't have great arguments against generalizing startups to Big Tech Farm League. There are plenty of gripes up from startups against the Great Houses, especially from investors. But that's feudalism for you.
Compare, say, DHH's lobbying. 37signals had the Bezos investment, but it was an unusual deal, not within the usual system. Speaking from a different place.
I've never gone back to formalize the grammar or otherwise mature it. But it's served me well as-is, and it's been easy to convert "up" to JSON or YAML or XML or what-have-you, once the case for an interface beyond plain text proves worthwhile.
Lawyers absolutely read every word of court decisions—citations, notes, appendices, concurrences, and dissents. Usually multiple times. But that tends to happen when looking to cite, criticize, or argue about a particular decision that matters. In other words, when you might have to defend your interpretation against another lawyer. And when you have the time. Which is money.
Lawyers reading for other reasons may skim, hunt for specific passages, or even just glance any provided syllabus, depending on why they are reading. When you've read enough of these, by the same judges, living and dead, over and over, you get a sense not just of formatting and structure but written and thinking style, as well. You get better at determining whether and when it's worth a full, deep read.
One of the things American law schools teach by experience in the first year is that the level of attention, organization, and critical thinking expected in reading is far higher, in its own peculiar way, than what most students are used to putting in, even from very strong academic backgrounds. Then they develop endurance for it, by assigning many cases to read for each class session, several times a week, for several classes at once. All in a competitive environment where your hiring prospects largely come down to grades and your grades come down to a single exam per subject, each awarded on strict statistical curves.
Part of it's that you learn what you need to read. Part of it's that you just grind. When you've been grinding long enough, you don't even feel it anymore. It still hurts, but it's a long, slow abrasion on your mind and personality. Not a stitch in your side anymore.
I'll never tell anyone off from reading Supreme Court opinions. It's your court! As long as you can keep it. But for most folks reading for interest, the syllabus is fine. If you want just a little more than that, read the intro and concluding sections of the "opinion of the court". Then read the intro of each dissent, if there are any.
An astounding milestone for the English language.
Imagine what this sentence possibly could have meant in 1990.
I can strongly recommend Richard Moss' Shareware Heroes book for those interested in remedial reading, and not just for those devoted to games.
If there are any computer history grad students lurking, an integrative history of early software distribution models and industry orgs is still a big, gaping hole in the lit, as far as I know.
The amount of archival footage Curtis riffles through for his pieces is an impressive part of the story of his storytelling. It should also be its own implicit warning. The runtime of the footage he watched and did not include dwarfs the runtime of any single piece of his you might see. To be well read on any particular event, much less time period, that he jaunts through would take a stack of books and a lot of serious attention.
I'm not a UK lawyer, but the law they quote says nothing about the logic machines are programmed to follow presumptively creating reliable evidence. It could be read to say that computers should be presumed to be executing the instructions they're given reliably, unless evidence shows otherwise. It's about malfunction, not misapplication.
Perhaps some of the Horizon case decisions showed judges improperly presuming that Horizon calculated correctly, and not just that the computers were running Horizon correctly. But the article doesn't show they did, or even explicitly say they did. Conflating two separable issues, it fails to address whether or why different presumption rules for each might be desirable.
If you haven't read Hal Varian's Information Rules, I highly recommend it. Check the publication date, then read it anyway, then reflect on the publication date when you're done. I found it very worthwhile.
> In this guidance, we provide a framework for analyzing whether a digital asset has the characteristics of one particular type of security – an "investment contract."[4] Both the Commission and the federal courts frequently use the "investment contract" analysis to determine whether unique or novel instruments or arrangements, such as digital assets, are securities subject to the federal securities laws.
Fortunately, we have institutions where they can duke it out. And where we can fight about what the decisions mean.
Here's a guide they published: https://www.sec.gov/corpfin/framework-investment-contract-an... It summarizes the law.
The SEC obviously will not be publishing a release saying it won't enforce the law according to criteria written to suit cryptocurrency promoters. Its key public mission is investor protection.
That's playing pretty tight with definitions to push "crypto" out of the picture.
SEC's press releases was "SEC Charges Samuel Bankman-Fried with Defrauding Investors in Crypto Asset Trading Platform FTX". https://www.sec.gov/news/press-release/2022-219
The release said "crypto" ten times.
FTX appropriated assets for a hedge fund that bought and sold cryptocurrencies.
Why did they think they could run an exchange without complying with the laws for those? It was for cryptocurrencies.
There are few if any "crypto cases" in the sense of cases about breaking laws specific to cryptocurrencies. There are very few of those laws.
There are an awful lot of "crypto cases" in the sense of companies focused on cryptocurrencies breaking laws that long predate cryptocurrency. That is and should be affecting general perception of "cryptocurrency".
From the US law perspective, I understand that some courts have decided that non-exclusive licenses without stated terms can be revoked at any time. But I wonder about situations when a court looking at a permissive grant for open software wouldn't also bring contract and quasi-contract concepts to bear. There's clearly an expectation of reliance, MIT and BSD themselves contain contract-type disclaimers and exclusions, and what a licensor might get in return doesn't have to be money.
I generally advise developers, and believe most of my US colleagues also advise developers, to treat past releases under MIT and BSD terms as irrevocable, even though they don't explicitly say they are. But that conclusion comes as much from practicalities as legalities.
If the MIT license lets people make and share copies willy-nilly, online and off, how do you go about notifying every potential recipient that you've taken that license back? Even if you send a notice to just one user you want to block, who wants to see that on the Internet within hours? Who wants to be the company potentially arguing in court to undermine the reliability of MIT license grants generally?
On the legal side, sketching very roughly: The general rule seems to be that non-exclusive licenses without terms remain revocable by default. But in what circumstances won't a court find a contract or quasi-contract, applying those rules instead?
So much better to get ahead of all this head scratching by saying in the terms that those giving can't take them back. Alas, literally nobody's got commit bit on what we call "MIT", "BSD", &c. anymore. But we made very sure to do it the Blue Oak Model License: https://blueoakcouncil.org/license/1.0.0#reliability Other, more recent forms, notably Apache 2.0, say it, as well.
If you're reading this and thinking about a particular bit of software, don't rely on what I've written here. Talk through it with a lawyer who's up to speed on the latest, will ask you for specifics, and will stand professionally responsible for their guidance. I won't.