• 1 Post
  • 73 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.




  • 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.



  • barsoap@lemm.eetoNix / NixOS@programming.devThe future of software is Nix
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    2
    ·
    edit-2
    27 days ago

    Nix is typed: there are strings, paths, lists, attrsets, etc;

    Those aren’t types as far as programming language theory is concerned, they’re (using Rust terminology) variants of enums.

    It’s not really unityped (“dynamically typed”) either, though, but it’s a rather small wibble: Include paths aren’t normal values, they must be statically evaluable. AFAIU that was some prescience regarding enabling future addition of separate compilation and maybe even proper typing.

    Otherwise the language is just the untyped lambda calculus with a couple of primitive data types thrown in, just like lisp, scheme, or also lua or js (if you squint a bit), what makes it different is that it’s lazy and pure. Heck, it’s a language where you have to write down the y combinator (which wouldn’t work in typed lambda calculi) to do loops what else but the untyped lambda calculus is it supposed to be.

    That all said, nickel exists. The whole CLI situation as well the documentation is a mess because practically everyone is using flakes even though it’s not an official feature (yet). And, of course, nixpkgs is nowhere close to having been ported to flakes, AFAIK we’re not even close to starting. Personally I think it should be done at the same time as a move towards nickel as not to do it twice but that requires nickel to actually get integrated into nix (as in the package manager).

    tl;dr: NixOS is still very much in its “move fast and break the docs and all your habits” kind of phase. What it has going for itself, of course, is that “break things” doesn’t happen while that’s happening.




  • 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.



  • You can’t automate generation of shape keys. An artist needs to go over every single asset and make it work for every single extreme point on every slider, then make sure that the automatically derived in between points look good and fix those if required, in all slider combinations.

    And it’s probably still going to clip during some animations because going over absolutely everything is just prohibitively expensive.


  • Why is the term “Body Type A” and “Body Type B” present at all when there are clear pictures of the two options that speak for themselves? It feels like just going out of the way to include “the corporate approved buzzwords intended for maximum synergy with the brand!”

    “Type A” and “Type B”, I assure you, are not things corporate or marketing came up with. This is programmer speak for “I don’t want to name it but can’t call it foo and bar either because normies will be seeing it”.

    As said: This is a re-release. The game and its assets was originally never designed to support anything but a strict binary, but the pronoun vs. body type thing was trivial to do, so they did it. And then for some reason avoided “male” and “female” because face it that sounds like a good idea especially if you’re not overthinking it and the labels were left in because probably also easier to do. Or just didn’t consider the alternative.

    That is: You’re assuming intent when there’s simply economy of action. You might call it laziness, but then the people who did that release had 10000 other things to do besides that.




  • Games that do this aren’t being progressive or inclusive, they’re changing the color of the cup that my drink comes in and pretending it’s an entirely new beverage.

    The thing is… if you use “dude” and “chick” in the body type descriptions you’re implying gender identity. There may be better options that “Type A” and “Type B” but dude and chick ain’t it because it simply means male and female.

    In a very flexible system, you could use more granular options like “wide shoulders”, “wide hips”, “boobage”, etc, to freely mix+match everything. It’s also expensive to develop and even more expensive to create clothing for and a gazillion times more expensive to make really good-looking clothing for (fabric folds and flow aren’t easy). From a developer’s perspective, looking at the work involved really makes you want to say “We’ll just tell the player they’re now Geralt of Rivia and that’s it”.

    I think for most games the appropriate choice would be to have an early radio button, saying “male/female/it’s complicated”, the first two options hiding every enby option including pronoun selection. That’s right-out trivial to do and just good UX. And yes the body types should be called male and female, you already selected “it’s complicated” so it’s clear that when you’re selecting a body, you’re selecting a body, not identity.

    As to laziness: Eh. Noone’s going to start a research programme on how to do things in an optimal way for a re-release. Someone had a look at the code and assets and thought “hey we can support separate pronouns and bodies without doing anything more than providing an option” and that’s exactly what they did, using the extent of knowledge and consideration that was already in-house. Yep, it very well can happen that if you take your foot out of one thing, you put it right into another.

    As to “primary/secondary”: One of the options has to be to the left, or on top, of the other. Ain’t no way around that. I mean you could put option B on the left of option A to cancel things out but now you’re being confusing. More importantly you can make it so that none is selected by default.

    Am I onto something or is this all crazy talk?

    Yes and no you’re being quite personal, and I include your perspective shift into the POV of others in that, about things that will never make 100% of the people 100% happy because technical reasons. The perfect is the enemy of the good and all.