• 7 Posts
  • 852 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle
  • Algorithmic patents amount to patenting maths which, by very longstanding precedence, is not a thing, for good reason. Same goes for business methods and other stuff.

    In the EU there’s only one way to patent software and that’s if you’re using it to achieve direct physical ends. E.g. you can patent washing machine firmware in so far as you patent a particular way to combine sensor data to achieve a particular washing result. Rule of thumb: If, 30 years ago, you’d have an electromechanical mechanism to do the task then you can patent the software that’s now replacing it.

    Oh: It’s also possible to patent silicon, that is, you can patent your hardware acceleration methods for video decoding. That doesn’t extend to decoders running on general-purpose hardware, though.

    If you want to monopolise your brand-new hash algorithm there’s a simple way: Don’t publish the source, use copyright to collect royalties… though that doesn’t mean that reverse engineering is outlawed, especially if necessary for interoperability. Practically speaking nope hash algorithms just can’t be protected which is fair and square because it’s academia who comes up with that kind of stuff and we paid for it with taxpayer money. Want to make money off it? Get tenure.



  • The vast majority of sales are made to US based firms so they likely have a lot of sway.

    The sway is TSMC uses ASML EUV lithography machines and the US holds patents on those because they did foundational research regarding EUV lithography. Also, the EU hasn’t put China on the “it is illegal for EU companies to kowtow to US sanctions” list. Ironically ASML could sell to Cuba and Iran. If the EU were to tell ASML to sell to China the US would be free to not buy ASML machines any more and, doing that, kill off Intel’s fabs.

    None of this stuff has military relevance, you don’t need or even want to use small nodes (which require EUV) in military applications you want hardened chips instead. Run off the mill consumer chips go all frizzy if an EMP looks at them sideways. This is about the US protecting US fabs, foremost Intel. Not the chip design part but the manufacturing one.

    Europe hasn’t played the high-end end-consumer chip market for ages and I doubt we’ll do it any time soon. Having ASML, Zeiss etc. means that whoever actually produces that stuff wants to be friendly with us and strategically, both military and economy, our own production facilities are perfectly sufficient. Hence also why ESMC will only go as small as 12nm, it’s the most cost-effective node size and performance is perfectly adequate for a missile, a CNC mill, or a car infotainment system. Or the gyroscope chip in your phone (it’s almost certainly a Bosch), EUV doesn’t make a lick of sense when you’re doing MEMS. Where we have to catch up is chip design lets see how that RISC-V supercomputer chip turns out.



  • that meme makes is that it’s clear the gal doesn’t want to participate in the conversation due to body language.

    Not trying to argue against the meme, how it’s used and understood etc, but: You can’t interpret body language from a still image, you need at least like two or three movements, you need to see how someone reacts to their own movements so to speak. She might just as well be going “woah, cool”, slight backward surprise movement, and the two are the most wholesome couple you’ve ever met. Or she actually really wants to get out of there. That’s the point: The still image itself is too little information to make the distinction.




  • Plenty of self-driving trains around, generally metros where frequency and 24/7 operation is a great boon to overall service quality – you don’t want people to look at schedules, you want them to go to the station knowing there’s going to be a train in a couple of minutes, tops.

    It’s way different for long-haul service, freight, passenger, doesn’t matter. Longer and less frequent trains with way more passengers in them, and you probably need other staff too, like someone needs to run the bistro. The tracks they’re running on are also way less predictable, with a metro you can have station screen doors everywhere (which btw necessitate automatic driving, humans aren’t accurate enough) try that with an international train: Regions much less countries can’t even agree on uniform platform heights. Much less door locations: Automated long-haul would require dedicated platforms at every station and while those could be served by trains with drivers, trains nowadays are all smart enough that including a button “stop at exactly that location, to the half-centimetre” isn’t an issue, those trains would have to have doors at the right location. Now go ahead and convince Germany and France that they need to replace all TGVs and ICEs to have doors in the same location as your regional trains.

    Oh and none of that automation tech used with trains uses machine learning, btw. At least not at the basic level, when it comes to actually driving the train. I do remember watching a documentary about Singapore’s metro, where they have an ML algorithm scheduling track maintenance, minimising not service interruptions as such but impact on people’s commute. First the workers complained that none of the orders made any sense, then the developers made the computer spit out context and motivation alongside with the orders, workers changed their tune to “that’s fucking brilliant”.

    …which, actually, brings me to the conclusion: Also with automated systems we’re going to need maintenance which isn’t going to be automated any time soon. If you automate a metro that currently doesn’t run 24/7 you don’t have that many drivers in the first place, and probably have other jobs for them to do. Automating really is about making “a train max. every five minutes, 24/7” possible without breaking the bank.




  • Yes in principle to male plug, no to 240V unless the inverter sees a frequency to sync to. They won’t power anything during a power outage that requires the whole electrical installation to be set up for it so you don’t leak power to the outside and fry a lineman. Also that inverter attaches to one phase only which means that its power won’t even reach 2/3rds of your circuits. It does make the power meter go backwards though which is the point.

    That said, ideally you’re using Wieland plugs and not Schuko so you won’t have exposed prongs. The VDE certified Schuko for feeding in up to 800W though and that’s exactly the amount parliament said doesn’t require a permit or even talking to your utility. If you’re doing everything new going with Wieland is the sane choice those outlets don’t cost a fortune, if it’s an existing installation though a) your landlord might not like it and b) electricians will demand more in travel costs than the outlet is worth.


  • I think you dont fully understand how c compilers ( gcc specifically ) work when using multi file projects

    They don’t. C compilers compile single files produced by the c preprocessor (resolving all #includes), they have no concept of multi-file projects. That’s a thing for the build system, such as make, and it needs dependency information from the preprocessor to do its job (cpp -M), and once it has that it has to act correctly on them which is often completely broken because people don’t understand make. Like using it recursively, bad idea. In the wild, a random C project at work you’ll come across needs a full rebuild to build cleanly. Things have gotten better with things like cmake getting more popular but the whole thing is still brittle. GNU autohell certainly makes nothing better, ever.

    Also, anything using IL will always have an abi,

    Everything will always have an ABI because ABI is just API in the target language, whatever that may be. If your program is compiled and can run it uses an ABI.

    Wasm is wasm, and you only need an exposed interface

    The core wasm abi is less capable than the C abi: You get scalar values and pointers, that’s it. No structs, no nothing, memory layout is completely unspecified. The component model allows compilers to say “so I’m laying out strings like this and structs like that” giving linkers a chance to say “yeah I can generate glue code between you two”.

    Again, i like the idea of rust, but it has a long way to go to be viable atm.

    C isn’t even close to being viable according to your standards people just have gotten used to the jank.

    And it has many pitfalls to avoid so it doesnt become the hot mess that is any framework based on node.js

    Rust doesn’t have portable dylibs precisely because it isn’t a hot mess. Because it’s actual work to do it properly. Unlike everyone else. Meanwhile It speaks the local C ABI fluently (they differ by architecture and operating system, btw), which isn’t a thing that can be said about many languages that aren’t C.


    Differently put: What, precisely, do you want to do? Have you any actual use-case for your doubts, or are they spooks?


  • It’s a lacking point yes but unless you want to use a closed-source library it’s also a non-issue, which is why it has never been given priority. It’s not like language semantics would prevent portable dylibs it’s that there’s more important fronts to improve Rust on. A proper solution would take quite some engineering effort, and do note that C doesn’t have a proper solution either it just lets you link stuff up willy-nilly and then crash. Rust is actually in a better position to implement a proper solution than C is.

    The “big project” thing is a red herring given that rust compiles incrementally. I know it is technically possible to not rebuild everything from scratch in C but the code has to specifically written to not break assumptions your build system makes while rust is happily re-using the compilation results for one function in a file while discarding those of another because actual dependencies are actually tracked. Out of the box.

    Speaking of large Rust projects and proper type-safe linking: The WebAssembly folks are hashing out their Component Model which isn’t really limited to compiling to wasm, in principle: Big picture it’s a way to programmatically specify ABIs and even derive ABI translation code. That might be a good option as a rust-specific solution would be, well, rust-specific and when you engineer something that can support multiple versions of a language you can just as well engineer a bit more and have something cross-language.



  • The Rustinomicon has a chapter on it. The basics are quite simple: Declare non-opaque types to use layout matching the C ABI, export/import functions, some wibbles around name mangling. Option<T> vs. null pointers. Where things get a bit more involved is unwinding, but then you’re at the end of it, nothing should be shocking to anyone having written C.

    As to how Rusty it is… not very. I mean Rust has first-class FFI support, but the way FFI stuff is written is necessarily unidiomatic because you’re basically writing C in Rust syntax and you won’t get out of declaring your own functions `unsafe’ before you read the rest of the Rustinomicon to understand what properties you need to ensure because the nice and shiny parts of Rust assume them.



  • ROMs back then got erased by UV light, EPROM. EEPROMs are a bit newer (though still ancient) and can be erased electronically, nowadays it’s a very sane idea to just throw flash storage at the problem. I think you can get modern replacement for pretty much any ancient form factor.

    The way those things are used are basically big logic tables: Instead of using a bunch of logic gates, you store the output that’s expected given a certain input. Completely ancient technique, the limiting factor is storage space and sensibility – storing all addition results of two 32 bit numbers uses a lot more transistors than a 32-bit adder, but if what you want to put in there isn’t a thing that can be implemented few standard TTL components throwing storage at the problem makes sense even if you never plan to reprogram it because burning a custom set of transistors onto silicon is expensive.


  • Some more technical info.

    It’s an legit 8-bit CPU implemented with TTL chips, what makes it a different beast than what they did back in the days is that its microcoding isn’t kneecapped. It would absolutely have been possible back in the days to build exactly such a thing, even from precisely those components. At least the TTL part, that is, I bet there’s wibbles around VGA etc. And because I already hear the detractors yes, 8-bit CPUs were microcoded: They decoded single external instructions into a stream of “load from memory, fetch from register so and so, switch on the ALU, put what’s in the ALU output somewhere”. They kept it as simple as possible and it wasn’t reprogrammable but that stuff there, that’s microcode.

    Implementing CPUs in TTL chips also isn’t a new idea, that’s how early minicomputers were made (later on they got some specialised chips). And those things also used ROMs for their microcode. So you could say that this is a minicomputer capable of pretending to be different 8-bit microcomputers.

    FPGAs are a completely different technology, those allow you to arrange logic in a (more or less) arbitrary topology. That is, looking at that board with all those TTL chips, it’d be the equivalent of being able to re-route all the board traces as you please.


  • Data after dst+n is unchanged.

    Sure but that means the part before that is garbage because you have a null terminated string without terminator.

    Or at least that’s how I see it. If your intention isn’t to start and end with a null-terminated string you should be using memcpy. Let us not talk about situations where CHAR_BIT != 8 that’s not POSIX anyway.

    Even better, just avoid doing string manipulation in C.