Re: Where's Elon then?
Like many tech executives, SatNad aspires to Elon-nature.
12336 publicly visible posts • joined 21 Dec 2007
That paper's conclusions are over-generalized. The studies they cite for the decrease in productivity looked at a pool of call-center workers for a single firm, "IT professionals in a large Indian technology company", and data-entry workers. The first and third are low-skill, low-reward jobs that are tremendously different from high-skill knowledge-worker positions. The second group found that overall productivity was consistent between at-office and WFH, but that WFH employees recorded longer hours and so were less productive per hour. Productivity per hour is meaningless for knowledge-worker positions, because 1) rate of work is much more likely to be a lifestyle choice or influenced by other commitments, and 2) you don't get more output by forcing knowledge workers to work more hours, due to limits on cognitive load (and labor factors).
So it's utterly irrelevant for most or all of the people commenting here.
But, hey, good attempt at putting up a strawman.
For the past 30 years, I've worked on small, geographically-distributed teams. We've never needed to be physically in the same place. Partly that's because, yes, we're better than everyone else in the world; but partly it's because this "better in person" myth is bullshit.
Exactly.
Most competent developers shouldn't be writing a lot of new code, on average. Their time should be dominated by other activities: design, research, refactoring, reuse, testing, and so on. Writing a lot of code is a process failure, in most cases. It's inefficient and tends to produce more technical debt and defects.
Oh, I think plenty of us could tell it was sarcasm. Even Muskolytes wouldn't describe Tesla's iPads-on-wheels as "minimalist".
At least we can all agree that climate change is entirely caused by people driving existing ICE cars, though, and will be completely solved by making everyone buy a new electric vehicle.
Family gatherings tend to reduce load, because instead of using discretionary power at two (or more) households, you're using it at one. Cooking a meal for a bunch of guests means they're not doing their own cooking at the same time. National holidays reduce power consumption at workplaces. November in the US reduces A/C power consumption.
As for personal solar, it's negligible at grid scale. The EIA says that residential PV installations in 2021 were under 4 GW total capacity. Even if that's all producing as much as possible, averaging 12 hours/day, that's 48 GWh. US electrical consumption in 2022 was over 4000 TWh. Five orders of magnitude – residential PV is a rounding error as far as the grid's concerned.
(And some of us have gas ranges. Some of us also ignore the annual festival of stupidity called "Black Friday".)
Of course this is the beauty of regulatory capture.
Amazon et alia continue to use dark patterns because 1) they can, 2) those patterns still offer some value, and 3) everyone else is. But for large, established players, dark patterns offer less benefit than they do to upstarts. Amazon's scale means that it doesn't need dark patterns to advertise Prime, and it can offer benefits with Prime that most customers will perceive as having some value.1 Dark patterns likely only contribute a small portion of Amazon's conversion rate.
So this "do as we say, not as we do" approach by the big online platforms works to their benefit, even if they have to change their practices.
That's not to say it's not good for consumers. It's just that there's an advantage to the big players in leveling the field.
1I don't, because I don't care about getting my purchases faster, on the rare occasions that I buy from Amazon, and I don't care about their television offerings; there are a few I watch occasionally because my wife has a subscription, but I wouldn't miss them at all if I lost access to them.
Putin had publicly stated that he considered Ukraine to be an integral part of Russia and not an independent country
More importantly:
1. Sevastopol is the only good deep-water port in the eastern Black Sea. Russia has to control Sevastopol if they want to be able to project naval power effectively into the Mediterranean and through the Suez into the Arabian Sea, and on to Africa, India, etc.
2. Controlling Sevastopol requires a friendly nation control Crimea. When Ukraine pivoted toward Western Europe and the USA, it became unfriendly, so the only remaining candidate was Russia itself. (Crimea also contains a bunch of Russian-identifying people, of course, but despite public rhetoric I can't see this being a major factor in Putin's calculus, aside from making holding the peninsula somewhat easier.)
3. Crimea is poor land. Potable water and arable land are in short supply. It has to be supplied from the mainland. Russia's bridge to it was vulnerable, and indeed was successfully bombed. To secure Crimea, Russia needs a land bridge, and the only one is through eastern Ukraine (which also has a lot of Russian-identified inhabitants, but parenthetical from #2 continues to apply).
4. Russia has now made the situation worse for itself, because the war pushed Finland to join NATO. Hostile Nordic countries, particularly Finland, severely imperil Russia's Arctic naval bases and ability to project naval power through the Arctic and the Baltic.
5. Also, polls (to the extent they're reliable) show that Russian citizens overwhelmingly approve of the war, so it's important for shoring up Putin's power and the cult of personality that feeds his ego.
Russia really, really needs Sevastopol if it's going to continue to regard itself as a superpower. Let me be clear – that in no way excuses either the invasion and annexation of Crimea, nor its behavior in the current conflict. But this war is not about Putin's personal beliefs or his tenderheartedness toward ethnic-Russian people living in Crimea and the eastern Ukranian provinces.
It may well be useful for you. At Mountain Fastness 1 and 2, we don't use enough electricity for more instrumentation to be useful.
Even at the Stately Manor, which used significantly more for various reasons (bigger, fans running most of the time in the warmer months, etc), instrumentation is unlikely to have helped. On a per-appliance basis, perhaps; I discovered at one point that the dehumidifier in the basement was using a lot more power than I expected, and got rid of it (we were close to selling the Manor at that point so I didn't bother with a replacement). But for the meter itself? No, not useful.
When we had the Manor the local power utility kept sending us letters urging us to get a smart meter that would adjust the thermostat to reduce A/C load during peak hours. We declined, as we didn't have air conditioning, and reducing it below zero seemed implausible.
There's a ton of information in IP packet metadata that's useful to data thieves (including appliance manufacturers). And while most HTTP traffic is over TLS these days, and HTTP dominates home-user traffic, glossing that as "most data" could be misleading.
For WiFi with WPA, if the hostile device has the PSK (the WiFi "password") and captures the initial handshake when a device joins the network, then cracking the individual device's session key is pretty trivial.
This is probably illegal in at least some jurisdictions (IANAL), but technically feasible.
Even without breaking WPA, a device could snoop metadata and report how many devices are connected to the network, what off-network peers they connect to, and so on. That reveals quite a lot of information.
"Make targeted advertising illegal" is nonsensical. How would you define it? Generic OTC medications in the US often have text similar to "Compare to <brand name>" on the packaging – that's targeted advertising. And in the US a blanket ban would almost certainly fall foul of the First Amendment.
Frankly, I've found targeted advertising occasionally useful. In particular, on my Amazon Kindles, it's led to my discovering a number of authors I wouldn't have found otherwise, including some new favorites.
Unfortunately even Linux + WINE isn't a viable option for my work system. IT here make some effort to support Linux (and MacOS) for developer systems, but we're so heavily dependent on MIcrosoft for communications and office work that it's a substantial burden on the end user. And I have to sometimes develop for .NET Framework, which is not fully ported to Linux and never will be. (This is a product that relies heavily on WCF, among other things.)
Even for my personal laptop, the path of least resistance has been to keep the preinstalled Windows, add Cygwin so I have a decent CLI, use Pale Moon and Vivaldi for browsers, and run Linux (Kali for hackage, Tumbleweed for regular stuff) in VMs when I want it. Honestly for most of what I do, Cygwin is fine. At the moment I have Windows vim/gvim for editing, but at some point I'll probably switch that to Cygwin/X's vim and gvim, as I have on my work laptop. The main thing, for me, is having pure-CLI toolchains for development. I use LyX for writing, and LibreOffice if I'm forced to deal with Microsoft's file formats.
The mattress-gaining-significant-weight myth was made up from whole cloth by a mattress marketer. It has no basis in reality.
And biological "contamination" is everywhere. It's not like new cars are sterilized before you take possession, and even if they were, they wouldn't remain clean for long.
While sensible hygiene is certainly a major health factor, worrying about this sort of thing is just dangerism.
Your TV, headphones, fridge freezers, witeless speaker systems, personal computers, smartphones...
Er, not my TV, headphones, refrigerator, computers, or smartphone. I don't own any witeless speakers, or even witeful ones, so that's not a concern.
It is still possible to do without "connected" crap. Yes, in many cases it requires more work, but in others it's quite simple. We just bought an LG range for Mountain Fastness 2.0, and simply declined to connect it to the network. Nothing of value was lost. The new dishwasher and refrigerator don't even have connectivity as an option, and they're reasonably high-end models. With TVs, true, it's getting harder; when the current one dies, finding a suitable replacement may take some research. (Fortunately neither of us care about picture resolution or sound quality, nor do we need a large TV.)
Well, there's this, for example. There are many more.
Voice assistants were The Next Big Thing somewhere between cryptocurrency and LLMs. They didn't tank quite as hard as some of the Next Big Things (hello, Google Glass!), but they underperformed dramatically and lost favor with the add-on developers.
Federal parole was essentially abolished by the CCCA in 1984. It's my understanding that absent a pardon, the final sentence (after appeals) for a Federal crime in the US should be at least 85% served before an inmate is eligible for early release, though I haven't found a specific citation to confirm that. With the 1994 Crime Bill the Feds also incentivized states (with additional funding) to impose the 85% rule for certain felonies, and apparently most of the states took up the offer.
So contrary to what OP claimed, this guy should end up serving most or all of his sentence.
Indeed. Judging just from the quality of their output, a large percentage of programmers are terrible at their job. Automating the production of lousy code will not improve the dire state of the industry.
If you're a decent programmer, it's unlikely that most of your time at work will be spent actually writing lines of code anyway. Per Amdahl's Law, automating part of that portion of the work is not going to realize a large return anyway.
That said, I can see using tools, including generative LLMs, to create testcases. Most software projects I've seen are very far from the point of diminishing returns in testing, so additional testcases are likely to offer significant value. Obviously this can be abused (it's not a substitute for all other forms of testing), but it could contribute to quality.
It's also possible for an LLM to be usefully incorporated into static analysis, though I'd expect a bidirectional transformer architecture would have significant advantages over the unidirectional ones used by the major public models (except for InstructGPT, which IIRC is bidirectional).
For me, Battlefield Earth (the novel; I haven't seen the film, which is said to be execrable) falls into the "so terrible it's actually kind of enjoyable" category. I read it two or three times as a teenager, shaking my head at the inanity of it all – the pseudoscience (the Psychlos are made of viruses! their atmosphere explodes on contact with uranium!), yes, but also the amateurish characterization, plotting, and concepts – but carried along by its pulpy exuberance. I'm glad I read a great deal more of good, and even mediocre, science fiction, though, or it would have given me a terribly distorted view of the genre.
the cyclic references described won't be GC'ed
Modern (like, since 1970) garbage collectors nearly always use algorithms that handle graph cycles just fine, thanks. Mark/sweep and color GC find the transitive closure of reachable objects and collect the rest. Sometimes those are augmented with various optimizations, such as generational collection or heuristics for identifying theoretically-reachable but never-reused objects. (The latter is in general uncomputable but can often be decided in practice for a non-negligible set of objects.)
Similarly, many modern GCs support weak or abstracted references which don't prohibit collection of the referred-to object, which a program can use during the object's lifetime without interfering with collection.
GC isn't suitable for all use cases, but trivial problems like orphaned object cycles were solved long ago.
It won't be happy with plenty of possible C99 or C11 source either, like anything that uses "new" or "class" as an identifier, for example. Or that uses implicit conversion of void* to a specific object pointer type (which is preferable over using a cast, in C, since the cast can hide various errors).
You cannot write a device driver, a task schedular, or a memory manager in go, C# or Java.
You most certainly can. At the limit, you can use the Kolmogorov-equivalency approach: You write an interpreter for the desired language in some language suitable for the target environment.
More generally, there's nothing that inherently prevents directly writing any of those three things in any of those three source languages, except possible ABI issues. Any of those languages could be compiled to native code, if that's a requirement of the environment (and such a requirement is itself arbitrary).
The issue is that it is not possible to guarantee that C code is safe
It is not possible to guarantee any non-trivial program is safe, because "safe" is not well-defined and security is not an absolute.
The programmer's intentions may not match the user's intentions. The user's intentions may not match their desired result, or the result desired by the owners of whatever resources are affected. Everyone may have the correct intentions but there may be unanticipated adverse consequences.
Adding security mechanisms to a language – as Rust did, with its strict object-ownership rules – prunes branches off the attack tree and removes some failure modes. The same can broadly be said for using modern C++ idioms (though in significantly different ways and with significantly different results) versus C and C++. But these are quantitative differences, shifting some of the work of improving security from the programmer to the machine, not qualitative ones.
Yeah. The FIPS 140 mandate has also gone well.
A part of "the U.S. government"1 can, and often does, mandate all sorts of things. Compliance is generally poor, as any number of audits by various Inspectors General and the like keep finding, over and over.
Government agencies need to get things done. They're going to try to buy software that lets them get things done. Obeying mandates from on high regarding that software is pretty far down on the list.
1The phrase "the U.S. government" isn't particularly meaningful. Even if we assume the writer means the Federal government, that's a huge, heterogeneous entity.