namark @namark@qoto.org

https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07

ok, cool thread, but the dongle works on Linux trisquel 4.15.0-142-generic just fine without any such workarounds and doesn't work on anything past 5.4 with or without these such workarounds...

wow these bozos were quick to cash in on MY IDEA
https://battlebeavercustoms.com/products/ps4-d-buttons

who would by that though, are PS4 dpads made of adamantium or something?

@maunye oh noo... nonono... don't mention the submarine model, cmon, fake news 101... can't do anything right...

joke's on me, spend the whole day to find this troll of a bug
https://gitlab.com/xboxdrv/xboxdrv/-/issues/144

nevermind random crashes, constant misconfigurations and irreconcilable video driver issues, just sitting there for 60 seconds has gotta be the most infuriating bug ever... go ahead and figure out why nothing is working when everything is right... low priority, cause wait a minute... it still works

@miria notwithstanding that physical phenomena are merely approximated in most applications, a description has many properties other than accuracy, such as simplicity, generality, expressivity, any pair of which are in conflict with the other. I it's simple and general, it's likely not expressive enough, general + expressive = too complex, expressive + simple = too specific. Balancing these (and probably many other subjective criteria) to fit a human mind best is the name of the game.

this actually worked, feels and plays better than any dpad I ever tried, and that's for any type of game, other than maybe some hypothetical no tolerance rhythm game where you'd need to develop muscle memory for quick and precise diagonals. The shape and the position of the buttons is really important, but them being a one piece is just defective design.

manjaro I have: drm + kernel can't figure out how to 2 monitors or who's fault it is

trisquel I want: "not an absolutely ancient gpu? nope!"

guix I want: failed to install itself with a cryptic lisp stack trace and borked my grub

xubuntu LTS I get - just works

my granma is on xubuntu and I'm on xubuntu cause xubuntu just works

fixed it

here is how you do it properly
https://yewtu.be/watch?v=zAT4YzVoAqU
you mount the buttons sideways, press them by pushing a lever around and get proper feedback when changing directions, especially from axial to diagonal. I'm pretty sure I had a tiny knob version of this on a flight stick, much smaller than most dpads.

Laying them flat is cheaper? Sure, but then stop gluing them together and pretending you made a stick.

what's the deal with dpads? It's like you wanted to make a crispy 8 directional joystick, but decided in advance that you are going to fail...

@codewiz the main point is that it's a nuanced issue out of scope for chrono. Any halfway solution would achieve very little and lower the quality of the library. The arithmetic bound checking is universally applicable, so it would be kind of silly to have something for durations that you couldn't use for other types. Also imposing any sort of compile-time, run-time or maintenance overhead any such checks would bring is nonsensical in a world where everyone in every other application of arithmetic is perfectly happy to just use a type that is assumed to be "large enough" to represent any value. Most just want to use a 64 bit int, and forget it can overflow, even at nanosecond precision, and some would vehemently argue that even on systems that don't have wide enough words, it should just be emulated in software.

@codewiz you seemed to have a problem with the concept so that was an explanation and a proof of concept implementation. Pleasantly surprised it worked at all! If you care about it you should participate, cause as far as I know that is the most developed of any such concepts:
https://github.com/boostorg/safe_numerics

common_type trait sounds like a misnomer, but I imagine chrono didn't have anything better to use. safe_numeric may provide alternatives on that front, though it will likely never be standardized in it's current form. It's much more likely for a more generic numeric library to get in, that would also handle arbitrary precision and provide the safe_numerics functionality as its subset, and probably not called "safe" cause that's not a very good name either.

@codewiz exception, abort or compiler error?

yes

https://yewtu.be/watch?v=93Cjg42bGEw

https://www.boost.org/doc/libs/develop/libs/safe_numerics/doc/html/index.html

@hobson yeah in a garbage collected language such designs often are emergent. Like for the GUI wizard each screen would just have a reference to the previous and next screens and you'd get a doubly linked list without even realizing it. You don't necessarily need a rigid data structure, and otherwise you can at least arrive at it indirectly, and layer maybe even improve the clarity of the code by identifying it and substituting a library implementation.

Rust slapping you in the wrist and preventing such patterns at compile time can be really confusing, and it often feels like you need to be a c++ expert to correctly resolve some of these situations and not resort to workarounds.

@hobson
> what is the quintessential use case for a linked list

There is no quintessential use case, there are many different use cases, real and potential. What I've encountered in the wild can maybe be split in two major categories:
1. High level control flow. The nodes of the list represent the entire state of your program, and the list itself becomes some sort of a self modifying linear state machine. It could be a GUI wizard with next and back buttons for example, that decides what screen to show based on user input and system state. Nodes represent the screens, traversing and modifying this linked list is essentially your whole program in that case.

2. Optimization of complex algorithms. When you need to insert or remove elements from the middle of the container often, a linked list with a custom allocation strategy can be your best bet. I think there is an example of that somewhere in these lectures
https://yewtu.be/playlist?list=PLHxtyCq_WDLXryyw91lahwdtpZsmo4BGD
https://yewtu.be/playlist?list=PLHxtyCq_WDLXryyw91lahwdtpZsmo4BGD
when implementing some sort of a tournament scheduling algorithm. Shame they don't have meaningful titles...

In both cases the memory allocation pattern is irrelevant, as in case of 1 the iteration is slow by definition, it's a high level logical state change, and in case of 2 the allocation is handled separately and not tied to logical creation of nodes.

I'm sure there are many more examples where the data structure can be used, and there are many more potential use cases. The whole idea of a linked list is that you can independently modify parts of it in various ways without affecting readers or writers that are working on other parts of the list, even in parallel. This goes directly against rust model of safety for containers.

The argument of "it's not cache friendly" is just a marketing cop-out. Ignoring that memory allocation strategy is not in any way definitive of the data structure and then telling people they should be aspiring to write their code with idiosyncrasies of some popular CPU architectures in mind, and that everything that doesn't fit in that box is just a useless niche is either naive or sinister.

> be more efficiently and securely implemented
Note than rust's model of safety is not synonymous with security. Expressiveness of the language is more important for security than any mechanical guarantees you can provide. Programmers need to be able to understand the code to maintain it correctly, and if a linked list is a perfect fit for the given problem it should be used. Can you substitute it with something else that is just as efficient and adheres to rust safety model? In some cases - maybe, but even if you do you will certainly be sacrificing some expressiveness and ergonomics.
Said expressiveness also helps the compilers to optimize code for various architectures, not even just CPUs. otherwise if you are thinking of a specific architecture, you'll have to throw all the code away for the next one. (Or, you know, you could instead acquire an international monopoly on software by abusing copyright and force hardware manufacturers to come up with increasingly perverse designs, to optimize your inline assembly code).

> Aren't there libraries for that?

Here are my thoughts on using a library implementation in rust:
https://qoto.org/web/statuses/107394401941447264
Rust is so fundamentally against linked lists that you can't even use a linked list properly. As workaround they introduce the notion of a cursor, which makes lists into special case, not eligible for any generic code that handles containers, so really a backwards hack, that doesn't even unlock the full potential of the structure, since it only models the "single writer multiple reader" scenario, which is the best safe rust can do. You might ask yourself where did this cursor thing come from? The answer is in rust's intrusive linked list library,
https://docs.rs/intrusive-collections/0.9.0/intrusive_collections/
where you can finally witness the concession under the Cursors section: "This is similar to how a C++ iterator works". Never in any front facing marketing material though, that would be disastrous.

I might difficult to understand if you haven't worked with or these data structures, especially in context of c++ standard library, were rust draws its inspiration from, but for anyone who did, I assure you these things should be obvious. Linked list is an example of a major weak point in rust, and the big question is how many other safe and efficient programs can you not write if you adhere to rust's definition of safety.

@johnabs
> Monopolistic business practices are known to cause economic hardship, as do oligopolies/cartels

Locally yes, but these IP monopolies are held by many US corps globally. I highly doubt you can offset that revenue with local business. The money not going to US government through taxation does not mean that it does not come back to US in one way or the other. The government has also other interests in proliferation of these monopolies that are ultimately its "subjects", than just taxation. If we are talking about reforming IP law to something like copyleft, it will not just be a detriment to companies like Apple or Microsoft, it will be their end. They will no longer be able to do business in any capacity, except maybe some small local software repair shops (the type of which which currently do not exist anywhere in any meaningful way, and that is not a coincidence). The world will be a much better place, but US (and others who rely on these practices) will end up weaker and poorer as a result. This is why I think such a reform will never happen in US. Now whether it is necessary or not for "right to repair" is a separate, though more important thread of discussion, since that's what most people argue on.

> The fact that making direct Apple chip knockoffs hasn’t taken off in China...

They are indeed plenty of knockoffs there, but they didn't take off simply because they were not marketed. In case you didn't notice this entire snake oil industry hinges on marketing. I'm sure you do not actually think that apple products are some kind of gold standard of quality that everyone is just itching to copy. There are no standards. There is no competition for any standards to form. There are only international monopolies riding on pop culture fads.
The problem isn't that it's not economically viable to copy apple in china, there is just no reason to do it. There would be plenty of reason to do it on countries where Apple's fads are rennin successfully. I mean at this point you are content with their product being crap right? You are just pissed that you can't repair that crap cause someone just decided to not sell you a part. Well I'm trying to explain to you how someone deciding to not sell you a part can even be something that can stop you. If you car manufacturer does not want to sell you a part, you go to a local machinist pay a little extra and get the part anyway. If enough people want it, you can arrange a production, cut the costs a bit and make a business. You might actually end up making better and cheaper parts if you are good at it.

> I don’t want the secret sauce to manufacturing the chips/tires/whatever

The IP stronghold does not protect the secret sauce of a particular manufacturer on how they can make so many of those parts for so cheap, it protects the functional logical description of the chip, the equivalent would be your car being welded shut everywhere it can be, and you being under legal threat for trying to bring an angle grinder to it. The secret sauce remains secret as long as you keep it secret, and no you can't tell how a thing was made by just looking at it, it's neither true for machined metal parts, nor molded plastic, nor ICs, you can only tell their function by looking at them, and if you are experienced, think of ways you could make them, and maybe independently rediscover the secret sauce, or an even better sauce, all of which you are prohibited under current IP laws, when it comes to ICs.

If you just treat the symptoms by weirdly specific and vague laws like "you have to sell parts" or "allow independent repair shops to acquire parts", without addressing the root cause, tomorrow you will be exploited in yet another way. Rossman has been there and done that, they passed a bill in one or the other state, and it turned out to be useless. Any other bill that is addressing symptoms will be just as useless IMO, and any bill that addresses the root cause will never pass in US.

@zpartacoos

@hobson @hackernews@die-partei.social most people expect to deal with same numbers they learnt about at school and for algebra to work the same way. That's what singed int represents, the whole numbers you learnt about at school, with a precondition that you stay away from large numbers. For the same reason javascript relies on IEEE floating point, python and common lisp go for arbitrary precision etc.

Teach people finite fields in school and suddenly unsigned will make a lot of sense to everyone, and will be the obvious safe default, but as long as you are teaching high arcane "real" numbers as if it's the most natural thing, most people will not have a single clue what's wrong with (a+b)/2 and what's the point of whatever the hell that midpoint implementation is (which is explained here and most everywhere rather poorly for the same reason), and they will write less wrong code more often if they stick with int, or better double, or better yet bignum.

Aside from not making silly mistakes when you barely put a thought into the arithmetic and algebra you are dealing with, cause you are conditioned to assume that it's easy-peasy elementary school stuff that you shouldn't think too hard about, the strongest argument in C++ for using ints in contexts where you do not need to represent negative quantities is performance. As an int conceptually represents a number that is not allowed to overflow (which you are expected to guarantee trough logical invariants), the compiler has more freedom to optimize it as an abstract quantity, for example to use a machine register that is larger than the representable range requires, which will not wrap said range on overflow. In this sense the language is lacking unsigned types with undefined overflow, and for completeness - singed types with defined overflow.

each logical component of a library should have:

smol brain: one file to represent it

big brain: one interface file and one implementation file to represent it

huge brain: one interface file, one type generic implementation file and one type specific implementation file to represent it

galaxy brain: one interface file, one type generic implementation file, one type specific inline implementation file, and one compilation unit file to rule them all, find them all, bring them all and in the darkness bind them all.

#cpp