430 karma · joined May 13, 2021
The real question is whether detransitioning or other negative outcomes are greater than the number of suicides prevented by allowing early transitioning, and that’s a rather more complicated hurdle to jump.
Of course we’ll need a way to resolve fluctuations both rapid and slower. Rapid fluctuations are handled by pumped hydro and increasingly by batteries.
The slow fluctuations (day/night all the way to summer/winter and good/bad weather patterns) are much trickier, I think it’s still unclear how well handle them, but it will certainly be partly handled by having an excess of renewables, though we’ll likely need some other solutions too, nuclear is probably one of them.
In the extreme case, as road coverage approaches 100%, the city stops containing buildings so the traffic will drop towards zero, so there’s actually a balance point somewhere, but roads are quite inefficient for high density cities, so probably the balance point would be less about fulfilling traffic demand and more about reducing the demand by demolishing most of the city.
Rust doesn’t have the kind of high performance garbage collection you’d want for this, so starting with unsafe makes perfect sense to me. Hopefully they keep the unsafe layer small to minimise mistakes, but it seems reasonable to me.
Here’s some ideas: 1. A data side channel 2. Use it to send originator for each message, have unique note on other end per sender so they don’t need to check visually, but also show on their display so corrupted or suspicious sender can be verified, in desperate circumstances (rather than the current case of “that cannot be done at all”). 3. Digital audio, allowing actual high quality audio, which we know does improve comprehension, which should not be optional in this context. 4. Take some lessons from modern coms systems on how to handle overlapping coms, plus the extra bandwidth from digital, so overlapping coms is handled gracefully (I realise the realtime nature prevents being too clever, but perhaps blocking all but the first to speak and playing a tone if you’re being blocked), perhaps with some sensible overrides like atc and anyone declaring an emergency getting priority. Currently overlap obliterates both messages and it’s possible for senders to not even know their message was lost. This has contributed to accidents, whilst basic direct radio transmissions cannot avoid this, smart algorithms with some networking could definitely reduce the failure cases to very rare and extreme scenarios 5. Let atc interact with flight planners on aircraft, show the aircraft’s actual locally programmed flight plan to atc, with clear icons if it differs from the filed plan atc has, and perhaps as an emergency only measure, allow atc to submit a flight plan to the aircraft (not replacing the active plan of course, just as a suggestion/support for struggling pilots, “since you have not understood my instructions 3 times, please review the submitted plan on your flight computer, note how it differs from what you programmed”) 6. Aircraft usually know where they are, and which atc they’re meant to be communicating with, have the data channels talk even when the audio channel is not set correctly. If incompetent pilots forget to switch channel, you can force an alarm instead of launching a fighter jet, or just have a button for “connect to correct atc” and a red light when you’re not on the correct one.
That’s just the ideas I’ve come up with just now. 4. Is probably quite hard to get right, and 5 could add load, so should be done carefully. But hard to believe the current system is technically optimal, or even vaguely close to optimal.
Admittedly, I know the real reason is that having 1 working system for everyone is better than a theoretically great system that is barely implemented and a complicated mess of handoffs between the 2. But with care they can absolutely improve things, but feels like things are moving a few decades slower than they should be.
> whether by phishing or exploiting the fact the passwords are weak or have been reused
1. Phishing is harder when you only ever enter your password into 1 place, and that one place is designed to be secure and consistent.
2. Much easier to have exactly 1 strong password than unique strong passwords for every website.
Is it better than a vault full of random passwords? Probably not, beyond pressuring the user into using the more secure method
Being forced to maintain compatibility for all previously written apis (and quite a large array of private details or undocumented features that applications ended up depending on) means windows is quite restricted in how it can develop.
As a random example, any developers who have written significant cross platform software will be able to attest that the file system on windows is painfully slow compared to other platforms (MS actually had to add a virtual file system to git at one point after they transitioned to it because they have a massive repo that would struggle on any OS, but choked especially badly on Windows). The main cause (at least according to one windows dev blog post I remember reading) is that windows added apis to make it easy to react to filesystem changes. That’s an obviously useful feature, but in retrospect was a major error, so much depends on the filesystem that giving anything the ability to delay fs interaction really hurts everything. But now lots of software is built on that feature, so they’re stuck with it.
On the other hand, I believe the Linux kernel has very strict compatibility requirements, they just don’t extend to the rest of the OS, so it’s not like there’s a strict rule on how it’s all handled.
Linux has the obvious advantage that almost all the software will have source code available, meaning the cost of recompiling most of your apps for each update with adjusted apis is much smaller.
And for old software that you need, there’s always VMs.
Same problem as ai safety, but the actual problem is now the corporate greed of humans behind the ai rather than an actual agi trying to manipulate you.
Caching and lower level calls are generic solutions that work everywhere, but are also generally the last and worst way to optimise (thus why they need such careful analysis since they so often have the opposite effect).
Better is to optimise the algorithms, where actual profiling is a lesser factor. Not a zero factor of course, as a rule of thumb it’s probably still wise to test your improvements, but if you manage to delete an n^2 loop then you really don’t need a profiler to tell you that you’ve made things better.
Nowadays the price arguments are… complex. But for the first time people actually care enough about the environment that nuclear is no longer competing poorly with coal (except for in Germany).
The exact maths on comparing pricing is complicated, given that energy storage costs vary so much depending on the inputs (try looking up storage costs for a 100% solar/wind grid during a once in a decade lull, it’d make nuclear look great, but obviously for a slightly mixed grid and more typical conditions, storage might be reasonably priced vs nuclear).
Anyway, I’m mildly disinterested in nuclear now that it’s only a side show to renewables, but I think it’s far from being a slam dunk either way. If some country or politian is more interested in nuclear, fair play to them, I say go for it. We’re not in a comfortable position right now so any movement away from fossils is a win regardless of where we end up (within reason of course)
No doubt the debate will only be resolved once and for all once fusion turns up and actually makes fission genuinely irrelevant (even then, fission might be cheaper for quite a while).
Rather the opposite for their customers.
I’m sure there’s a few cases where this would excessively hurt a company’s prospects (perhaps where a company has an innovative software product with a thin hardware component), but in the majority of cases losing access to the software of a hardware product as an asset is a relatively small loss, and the benefit to consumers is pretty huge. I’d support the trade off.
Yet I assume we can agree that regardless of how you can work around bad apis, good api design that prevents misuse is always better.
The safety measures have to stop somewhere of course (short of an api that is a single function which does exactly the thing you want without inputs or outputs, which seems unlikely), but extending type safety to interfaces does not seem like a step too far.
The cost of storing the size of every allocation is relatively high, at least some of the time, where it isn’t implied by the usage. Meanwhile the caching system for allocations can store it very efficiently, a block of 4KB of 8-byte allocations will contain over 500 allocations that can all share their metadata. Once they’re handed out by the allocator their shared origin is obscured, so they’d need individual tracking.
I do acknowledge that when size is inherent to the context (new or allocating for a specific struct) then maybe an allocator that doesn’t track size could allow for some clever optimisations, though I’m doubtful it could overcome the loss of shared metadata, which is so much more efficient.
It’s easier to justify improved efficiency when the cost of spilling carbon is a big number of dollars rather than a tiny slither of a global problem.
That said, I do agree investment should be limited, it’s obviously only going to be the “best” solution in the rare circumstance that there is no good solution.
AI will always behave differently to human cognition, we should expect them to have different illusions and different failure cases. That doesn’t mean worse, if they perform better than a legal human driven car on average then I don’t think there’s a justification to exclude them.
That said, they will probably have to be _significantly_ better than human drivers in order to survive the media and public perception, so this might be irrelevant in the end.
Games have massive cost efficiencies from scaling. Studios are incentivised to always make the biggest games they can with their budget. Games team sizes vary strongly with the project period. They can’t handle more than a small team early and can absorb almost any number of people at any skill level before release.
End result is that game development is always boom and bust. Small core teams build a game up slowly, then more and more are added until just before release when a mad scramble for anyone and everyone they can be bought borrowed or stolen to get the game released on time. Then there’s no work except for the core team on the next game.
The obvious solution is to have many games running in one studio to even out the team sizes and absorb the crunch, but that implies either studio sizes beyond anything we see currently (and no increase in per project scope) or much smaller scope for games.
I’ve seen models like they work, and be much less painful to work with for everyone involved, but it did require different market conditions to justify the alternative model, I’m not sure the entire industry could switch.
That’s not to say fixing the problem is impossible, just that the bad incentives will always be there to push back against improvements..
I found the preceding argument more compelling.
They had to invent the computer first, and before that they had to create a universe capable of sustaining both life and computers.
OOP has been around long enough that all the good ideas have been borrowed/copied/reinterpretted/stolen many times over. Any ideas that managed to remain unique to OOP all this time must have sucked.
It's true that a lot of the OOP ideas went into C++, but C++ has always been fairly agnostic to whether you actually use those features. Rust just seems to have taken that a little bit further.
The closest to an exception is inheritance, but it's been months since I've built an inheritance hierachy that wasn't just an interface that could be done with traits. When it comes up I happily use inheritance to do it and if I was writing Rust I would moan a bit and come up with an alternative design, but I'd hardly call it a big deal.
It seems like most languages built today have a thick vein of OOP in their design (discounting functional etc). You don't have to be 100% or 0%, Rust is way closer to OOP languages than it is to C.
Are you saying that the ownership/borrowing model for memory safety was a poor choice, or that it's possible to make a language on that model that has vastly less complexity than Rust?
Because your phrasing implies the second, but I don't think I've ever heard anyone make that claim before (presumably because there's no such language lying around anywhere, so it seems hard to defend).
If the first, then I'd point out that wouldn't be a language design flaw, but rather a flawed goal (ie a goal that proved too complex to achieve) - their goal was a memory safe language that didn't rely on a GC, and the resultant design complexity is basically the best example of a way to solve for that goal so far. I'm sure there will eventually be simpler options, but I don't think you can blame designers for not having access to undiscovered techniques. That's what most anti-Rust arguements boil down to.
If you just mean you don't like the syntax, then yeah, I agree, it's a bit alien for me too, but I hardly concider that anything beyond personal taste and the difficulty of learning something new.