Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)F
Posts
2
Comments
1231
Joined
3 yr. ago

  • Unlikely, you'd do packet processing in hardware, either through some kind of peripheral or if you're using RISC-V you could add custom instructions.

  • He's right. I think it was really a mistake for RISC-V to support it at all, and any RISC-V CPU that implements it is badly designed.

    This is the kind of silly stuff that just makes RISC-V look bad.

    Couldn't agree more. RISC-V even allows configurable endianness (bi-endian). You can have Machine mode little endian, supervisor mode big endian, and user mode little endian, and you can change that at any time. Software can flip its endianness on the fly. And don't forget that instruction fetch ignores this and is always little endian.

    Btw the ISA manual did originally have a justification for having big endian but it seem to have been removed:

    We originally chose little-endian byte ordering for the RISC-V memory system because little-endian systems are currently dominant commercially (all x86 systems; iOS, Android, and Windows for ARM). A minor point is that we have also found little-endian memory systems to be more natural for hardware designers. However, certain application areas, such as IP networking, operate on big-endian data structures, and certain legacy code bases have been built assuming big-endian processors, so we have defined big-endian and bi-endian variants of RISC-V.

    This is a really bad justification. The cost of defining an optional big/bi-endian mode is not zero, even if nobody ever implements it (as far as I know they haven't). It's extra work in the specification (how does this interact with big endian?) in verification (does your model support big endian?) etc.

    Linux should absolutely not implement this.

  • Not reliably though. I installed Kubuntu on a recent desktop just last week and had to revert it from Wayland back to X11 because every time it woke from sleep Plasmashell would crash and VSCode windows would be blank.

    Also it's 4% (of desktop, 1.5% overall) according to statcounter. Which is admittedly not bad, but I wouldn't say it's enough to say it has "happened".

  • Desktop Linux still hasn't happened...

  • They certainly tried (see Poetry, Pyenv, Conda, etc.). But that was mostly done by Python developers in Python, which is frankly the entire problem.

  • Probably not, because you can still publish on alternative app stores. Just not in the way that F-Droid wants it to work - where they build the app from source for you.

  • This is really naive. Mobile Linux is never going to happen for many reasons.

    It would be better to spend effort on lobbying regulators to prevent this move.

  • I hope this encourages the remaining Ruby devs to move to languages that aren't quite so awful to work with. Even Python is significantly better at this point, now that uv has mostly solved the tooling disaster.

  • No, an example where a modification to coreutils was open sourced by a commercial company that might otherwise not have.

    The GPL has been reasonably effective in some cases like the Linux kernel and KHTML at getting companies to release their modifications. But I don't see that as being significant for coreutils because a) most companies would have zero need to modify them, and b) they could just use the BSD versions if they really wanted.

  • *matriculation

  • Tell me one time when GNU coreutils being GPL has had any effect whatsoever.

  • Wow are there still SystemD naysayers? Mind boggling.

  • Kind of hard to tell without seeing the actual mod decisions. But usually these things are super opaque and the official discussions are super vague so it pretty much is he said she said.

    That said, this is definitely waaay better than the vaguebooking that the Rust mod team did when they quit.

  • I have. It just goes nowhere. The number of people you need to sign off what is essentially a donation is just too high. You always hit someone who says "why do we need to do this?" and the answer is "we don't".

    You need some actual benefit before most companies will actually pay money. It doesn't have to be huge though. Sometimes support is enough (as long as you don't also offer free support e.g. via GitHub issues). Phabricator did that and it seemed to work.

    Open core also definitely works. My company pays for GitHub premium because we need the features - primarily merge trains.

    They're very rarely going to donate out of the goodness of their hearts, and if you expect them to do that because you think they are morally obliged to then you're going to be disappointed.

  • Yes but why will it take market share away from Google? I can't see why anyone would use it. It's going to be slower, less well supported and not even any more secure.

    Servo at least has potential upsides: better security and performance. But another C++ engine is never going to have either of those.

  • Does it need another C++ browser engine though? I don't see what advantage this will possibly offer over just using Blink or WebKit.

  • I think when they're just a bit faster (like twice as fast) they'll be viable as a desktop computer for most people which is pretty cool.

  • Indeed, but there's no need to shit on people using floats because in almost all cases they are fine too.

  • That is default IEEE behaviour: https://en.wikipedia.org/wiki/Rounding#Rounding_half_to_even

    This is the default rounding mode used in IEEE 754 operations for results in binary floating-point formats.

    Though it's definitely a bad default because it's so surprising. Javascript and Rust do not do this.

    Not really anything to do with determinism though.