HN user
some of the dirtiest electricity generation in the entire world
In Europe. Still cleaner than the US, China, India, Japan, and the world avg:
https://ourworldindata.org/grapher/carbon-intensity-electric...
Coal and gas are down 50% compared to 10 years ago despite the shut-down. Nevertheless, shutting down the last few ones was bad.
It's the one thing I miss from Swift when I'm using literally any other language. Interal and external parameter names. I would love for Rust to adopt:
fn foo(namedParam internalName: bool) { // use internalName here }
fn foo(unnamedParam: bool)Just to be clear: There is an official notice of the EU commission making this legal argument:
https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:52...
Consequently, in the case of portable batteries included in products covered by Regulation (EU) 2023/1670, the removability and replaceability obligations set out in Annex II of that Regulation prevail over those set out in Regulation (EU) 2023/1542.
The ecodesign law (spare part but 1000 cycle exemption) pevails over the batteries law.
You are right that intraday went even more negative than day-ahead. But I disagree about the rest of your comment. A spread between day-ahead and intraday does not imply additional redispatch. Only some of it might have been countertrading by the grid operators.
The redispatch was not extraordinary: https://energy-charts.info/charts/power_redispatch/chart.htm...
So many questionable comments in here.
Negative prices have no effect on grid stability. It just means that the day-ahead market was cleared below 0, i.e. for every consumer (buyer) there is a producer (seller) selling at this price. The market is still balanced with consumption==production.
Now, you can ask the question: Why are so many producers willing to sell below 0? That has to do with misplaced incentives. For older or home-installed renewables there is a feed-in tarrif which guarantees a fixed revenue at all times. So there is an incentive to sell even for negative market prices. Newer installations can't opt for the guaranteed revenue model with revenue during negative prices any more.
Redispatch follows afterwards, if the market result clashes with physics: The physical grid can't transport the power from producer to consumer. There was no unusual amount of redispatch during easter.
Source: I work on this stuff.
Well it relates to this sentence:
You can use any credential manager you choose.
Which I would be careful with. I can use any authenticator that the RP accepts. I could totally see a future where banks only allow certain authenticators (Apple/Google) and enforce this through AAGUID or even attStmt. Similar to the Google Play Protect situation.
At that point, those banks/services would enforce vendor lock-in on me. The reality would be: I can use iOS or Android, but not a FOSS implementation. This restriction is not possible with old-school passwords.
Quoting your comments on github [0]
> There is no passkey certification process
This is currently being defined and is almost complete.
> no signed stamp of approval from on high
see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.
Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
[0] https://github.com/keepassxreboot/keepassxc/issues/10406#iss...
For DP adoption it's too late. They should push for USB4 / Thunderbolt 4 instead. We are in the phase where about every new laptop has USB4. Connecting your laptop/phone to a TV might be a selling point. I'd love that for hotel TVs.
Yes, HDCP is seperate from HDMI and DP.
The source and the sink need a HDCP-licence. Both devices have embbed keys that get exchanged to estabish a encrypted channel. Without the licence you can't get the required key material.
AFAIK, you can even sell HDMI devices without HDCP. Practically though, every entertainment device needs HDCP support.
All of those are i586 or i686 though right? AMD Geode LX is the only i586 CPU produced in the last 15 years.
Everything else is at least i686 and Rust has perfectly adequate i686 support.
Is there any major distro left with pre i686 support?
That's a really subtle version of the deadlock described in withoutboats FuturesUnordered post [0]
When using “intra-task” concurrency, you really have to ensure that none of the futures are starving.
Spawning task should probably be the default. For timeouts use tokio::select! but make sure all pending futures are owned by it. I would never recommend FuturesUnordered unless you really test all edge-cases.
I recently had to do maintenance on an old WPF app and bring it to .NET9.
I feel like at some point we are gonna complete the cycle and have MVVM/MVC binding engines in frontend dev.
There is barely any difference left between createContext+useSignal vs. C# DataContext+ObservableProperty.
I'm also surprised how often the preemptive vs. cooperative angle gets ignored in favor of the stackful vs stackless debate.
If you choose a non-preemptive system, you naturally need yield points for cooperation. Those can either be explicit (await) or implicit (e.g. every function call). But you can get away with a minimal runtime and a stackless design.
Meanwhile, in a preemptive system you need a runtime that can interrupt other units of work. And it pushes you towards a stackful design.
All those decisions are downstream of the preemptive vs. cooperative.
In either case, you always need to be able to interface with CPU-heavy work. Either through preemption, or by isolating the CPU-heavy work.
That's true.
Though, for my example, the storage location of the array metadata/fat pointer is not relevant.
In Rust you can hold references directly into the buffer backing the array (`&v[0]`).
My Java knowledge is quite rusty at this point. AFAIK, a `ArrayList<MyType>` in Java stores pointers to MyType in the buffer. So, when indexing into a ArrayList, you never hold references into the actual buffer. Instead you get a shared-pointer to the class data. It's the indirection of the array entry that saves you during reallocation of the buffer.
Also because Java is a GC'ed VM, it wont dealloc the elements references by the array, as long as there are other references to an element.
The equivalent in Rust is `Vec<Rc<MyType>>` where holding an `&Rc<MyType>` referencing into the vec's buffer is problematic during reallocation. But, cloning the Rc and holding on to it is perfectly fine.
The initial point of this thread was that you can have a Rust-like language where you can hold multiple mutating (aliasing) references and prevent use-after-free. This won't work. Without a GC or RC, you can use one reference to "rug-pull" the memory that is aliases by the other reference.
ArrayList is a wrapper around an array, and so adding entries will not move the ArrayList object, just the (wrapped) private array.
That's also how Vec works in Rust. Vec is just (buf_ptr, capacity, len) where capacity is the allocated size of the buffer.
The problem still exists though.
``` let mut v = vec![1, 2 ,3]; let x: &i32 = &v[0]; v.push(4); println!("First element {x}"); ```
The `push` might realloc the array. Then, x points into invalid memory. This is caused by the projection: You can create a reference to a field (aka member) from a reference to the base object.
A language without realloc sounds painful. Any growing container would lead to stale data.
You could pose the same argument against any form of warranty. Why provide/require any warrant for anything if the company might go bankrupt?
Yeah, then it gets messy. That's what the legal system and insolvency procedures are for.
You could require all games with online components to make their servers runnable by users from the outset
That's the strawman going around. You might not even have to provide EOL support for all online-components. Just use reasonable effort to make offline content playable. The law-making process hasn't even started and people already are arguing against the worst-case, least nuanced regulation possible.
The initiative is not even asking you to provide the full functionality of your online-components.
All you should have is a "reasonable effort" EOL plan that allows customers to continue using the parts that can work without the developers support. They even call out "Gran Turismo Sport" as a good example. Sony announced the EOL a year before, and stopped selling micro-transactions. Then they removed the online services while retaining offline support for add-ons and in-game items.
A reasonable EOL plan might be: We'll support the online matchmaking for 3 years. After that we retain the rights to shut down the services providing at least a one year notice. All in-game items and add-ons will be made downloadable for all players 6 months before shut-down. All offline game modes will remain playable using those items as before.
Assume your cycle detection D(TM, i) always outputs 1 when TM(i) doesn't halt (TM is the encoding of a turing machine and i is the input to TM). Otherwise, if TM(i) halts, D does NOT halt. [1]
We can construct a new turing machine F(TM) = D(TM, TM). That is: We ask D to detect a cycle when a TM receives its own encoding as an input. What is the output of F(F)?
F(F) = D(F, F) = 1 can only happen if your cycle detector detected a cycle in F(F) which we just saw terminates with 1. If F(F) doesn't halt, then your cycle detector claims that F(F) terminated, which it doesn't.
Therefore no such cycle detection can exist. It either has to bound the size of the input system or be non-exhaustive in its detection. The intuition here is: Assume the encoding of D has size N and D can check all encodings up to size N, then D must be able to dectect its own cycles. But the input to D(F, F) is size 2N (cause F is roughly the same size as D).
[1] If your original cycle detection outputs 0 if no cycle is present, then just wrap it in a TM that calls the original cycle detection and either returns on 1 or infinite loops on 0.
I'm curious how high up Guandong or Shanghai would be for example
Surprisingly far down: https://en.wikipedia.org/wiki/List_of_first-level_administra...
California, Texas, England, New York, Guangdong, Jiangsu. Both with slightly smaller GDP than Russia, the 11th largest economy.
More interesting is the PPP table where Guangdong is close to California.
Just in case you haven't read it, I can recommend this excerpt from "They Thought They Were Free." [1] It describes this exact feeling of "maybe I'm just being dramatic" during the rise of the Nazis.
[1] https://news.ycombinator.com/item?id=42943973
As someone who grew up next to a former concentration camp, the main takeaway when talking to survivors was: If you give the benefit of the doubt, you won't believe fascism has taken over until it's too late. You should talk to your friends and close ones and draw a line somewhere. Maybe it's once a US citizen gets send to El Salvador. Just something to agree on. Once this happens normal is over and we need to act. And organize locally don't stay on your own during these times.
I hope the best for the US.
I've never gotten this to work on an ISO-keyboard (chunky enter key). It opens "Help" in every single app, even Apple's like Finder or Safari. I've tried GB, German, US-International, and my default EurKey layout. None of them work. This shortcut always felt like an Alt+F4 prank to me.
As most of the kernel is in C, they probably need a raw pointer quite regularly to pass it into existing C APIs.
Just like `Box::into_raw`, this method shouldn't be used in pure Rust code. It's only available for C FFI.
Nitpick: There are actually a handful Rust drivers in-tree, e.g. https://github.com/torvalds/linux/blob/master/drivers/net/ph...
Though, I think all of them are direct ports of existing drivers.
This is similar to `Box::into_raw` in Rust `std`. It destructs the RAII struct into a raw pointer. After that it's pretty much expected that you are responsible for cleanup.
Most hosts will generate both a stable and a temporary address when using SLAAC. The temporary address will be used for outbound traffic but the stable address will accept incoming traffic.
So there usually is a stable ULA or link-local that you can put in a local DNS AAAA record.
The PITA is that many services prefer GUA over ULA if available and don't gradually fall back to ULA if the WAN goes down. And you will still need dynDNS to VPN into your network because ISPs are allergic to stable IPv6 prefixes.
it is simpler and thus the hardware could be faster
Is it though? With twos compliment ADD and SUB are the same hardware for unsigned and signed. MUL/IMUL is also the same for the lower half of the result (i.e. 32bit × 32bit = 32bit). So you're ALU and ISA are simple and flexible by design.
"Widespread" was maybe the wrong word, I was mostly imagining virtual memory on servers.
Currently, not all 64 bits are available for user-space VAs. Even with Intel's 5-level paging you can "only" get 56-bit (128 PB) of virtual addresses. On ARM they reserved parts the top-level byte for memory-tagging as well.
Remember with pointer tagging and overcommit you might have orders of magnitudes more VA address space used than available RAM. Exhausting 128 PB of virtual addresses in the next 40 years does not seem unfeasible to me. CHERI already exists in some niche.
It's quite intriguing to think about when and in which applications this bit-length churn will end.
For example, 64-bit UNIX epoch will work for 292 billion years. That's longer than the age of the universe and obviously enough. Meanwhile, signed 64-bit nanosecond (!) timestamps only range from 1678 AD to 2262 AD. That seems quite restrictive. So ultimately somewhere around 96-bits of time seems to be "enough" for any practical application.
For audio we've probably crossed the point already. Uncompressed audio is in the ballpark of a few Mbit/s. Humans will probably never need Gbit audio. What's the limit for video? Seems to be undetermined yet.
All of this will limit the max compute resources humanity will need for certain applications. Maybe we will see the widespread use of 128-bit computers during our lifetimes. Mostly for virtual addressing fun. But will 256-bit ever be needed?
Can confirm: Using Android 14 and Bitwarden, I can sign in to github.com using my passkey. It pops up a system dialog where I can select Bitwarden and then my Github username.
Last time I checked, the Bitwarden Vault export included the whole FIDO credential including the private key.
Generally, you can just give the disk to someone else. The physical disk contains the license key for the game.
The issue is that all modern games need to be installed on the internal SSD. So you're not playing of the disk, you're just copying the files from it. And many games require a day-1 patch to work properly. Some even require a constant online connection.
doesitplay.org is a useful database for that information.