• 24 Posts
  • 1.11K Comments
Joined 6 years ago
cake
Cake day: May 31st, 2020

help-circle
  • Ah shit, here we go again.

    I almost expected someone to learn that just from me posting. 😅

    Basically, OpenOffice used to be organized by Sun Microsystems. Then Sun got bought by Oracle back in 2010.
    Oracle does not have a good reputation at all, so the OpenOffice devs from back then figured they’d need to take things into their own hands and set up The Document Foundation to organize further development. But the OpenOffice trademark was owned by Sun/Oracle, so they had to rename and get a new homepage and everything. The name they chose is LibreOffice: https://www.libreoffice.org/

    After the OpenOffice project was effectively dead, Oracle handed it and its trademark over to the Apache Foundation, where it’s seeing occasional bug fixes. But to my knowledge, they don’t even have the capacity to fix all the security problems.
    All the actual feature development happens over on the LibreOffice side.

    So, in practice, if you want OpenOffice, what you really want is LibreOffice.


  • Yeah, not great. You always hope that projects under a larger foundation, like GNOME, have a higher bus factor¹, but unless that foundation has dispensible income to pay someone, you’re ultimately still reliant on volunteers and not many people volunteer for maintenance.

    What the foundation can do, though, which is also really important, is to hand over the keys to a new maintainer, should you disappear over night.
    Like, yeah, forking is great, but some people will never learn of the fork. It happens about once a year that I find someone online who’s still using OpenOffice and that project has been practically dead since 2011.
    So, I do hope we can get more open-source projects under some sort of umbrella. No idea how to actually do that, though. I also have open-source projects where I would not even know where to start to get them under some organization…






  • Ephera@lemmy.mltoMemes@lemmy.mlFacts
    link
    fedilink
    English
    arrow-up
    11
    ·
    4 days ago

    Oh man, I think it’s been taken offline, but there was a video podcast thingamabob on PeerTube, where two dudes would wax philosophically about politics, which they called “Dagoth Hour”. 🙃

    (The main baddy in Morrowind is called “Dagoth Ur” and he likes to wax philosophically.)



  • To give a quick highlight, because this case is often politicized and misrepresented:

    The plaintiff, Stella Liebeck (1912–2004), a 79-year-old woman, purchased hot coffee from a McDonald’s restaurant, accidentally spilled it in her lap, and suffered third-degree burns in her pelvic region. She was hospitalized for eight days while undergoing skin grafting, followed by two years of medical treatment. […]

    Liebeck’s attorneys argued that, at 180–190 °F (82–88 °C), McDonald’s coffee was defective, and more likely to cause serious injury than coffee served at any other establishment.

    So, the lawsuit never demanded McDonald’s to put a warning that you’re not supposed to spill hot coffee on yourself. It argued that it’s an unnecessary safety hazard, because the coffee was served at hazardous temperatures.
    No matter how many warnings you put down, it can happen that someone spills coffee on themselves and they shouldn’t need to be hospitalized from that.


  • Runtimes/“VMs” like the JVM also allow nice things like stack traces. I don’t know about the author but I much prefer looking at a stack trace over “segmentation fault (core dumped)”. Having a runtime opens new possibilities for concurrency and parallelism too.

    Rust has stacktraces without needing a runtime. Don’t ask me what exactly is going on behind the scenes, but there is a way to request a stacktrace for a given point in the program. And unless you’re doing embedded stuff, a stacktrace is automatically generated for errors.

    And as for concurrency/parallelism, it’s correct what you wrote, but I just wanted to point out that it doesn’t have to be a language runtime. Using Rust as an example again, you typically spawn the Tokio async runtime on program start, if you’re gonna do async/await stuff.


  • Ephera@lemmy.mltoAsklemmy@lemmy.ml*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    4
    ·
    11 days ago

    I find it annoying, because the hype means that if you’re not building a solution that involves AI in some way, you practically can’t get funding. Many vital projects are being cancelled due to a lack of funding and tons of bullshit projects get spun up, where they just slap AI onto a problem for which the current generation of AI is entirely ill-suited.

    Basically, if you don’t care for building useful stuff, if you’re an opportunistic scammer, then the hype is fucking excellent. If you do care, then prepare for pain.


  • Yeah, modern computers often feel like a scam. Obviously, some things are faster and obviously, we can calculate more complex problems.
    But so often, programs are only optimized until they reach a level of “acceptable” pain. And especially with monopolistic, commercial software that level is close to infinity, because well, it’s acceptable so long as customers don’t switch to competitors.

    Either way, the slowness that was acceptable twenty years ago is generally still acceptable today, so you get much of the same slowness despite being on a beefier PC.



  • Lots of “modern” languages don’t interop terribly well with other languages, because they need a runtime environment to be executed.
    So, if you want to call a Python function from Java, you need to start a Python runtime and somehow pass the arguments and the result back and forth (e.g. via CLI or network communication).

    C, C++, Rust and a few other languages don’t need a runtime environment, because they get compiled down to machine code directly.
    As such, you can call functions written in them directly, from virtually any programming language. You just need to agree how the data is laid out in memory. Well, and the general agreement for that memory layout is the C ABI. Basically, C has stayed the same for long enough that everyone just uses its native memory layout for interoperability.

    And yeah, the Rust designers weren’t dumb, so they made sure that Rust can also use this C ABI pretty seamlessly. As such, you can call Rust-functions from C and C-functions from Rust, with just a bit of boilerplate in between.
    This has also been battle-tested quite well already, as Mozilla used this to rewrite larger chunks of Firefox, where you have C++ using its C capabilities to talk to Rust and vice versa.



  • I think it was that back when it was relevant (but replace data scientists with web devs)

    Sure, but if programs from that era are still around, chances are the maintainer is quite experienced by now and has fixed all the funky behaviour. 🙃

    I never got interested in the ecosystem myself, but I’ve run into it every now and then. I feel like it’s in the same place as PHP today: still used a lot for legacy reasons, but you’ll get weird looks if you start a new project with it and you’re under the age of 40

    Ten years ago, a university buddy of mine discovered Ruby and you might’ve thought a miracle happened from how excited he was for it. But yeah, that was also the last time I met someone in real life who was excited about Ruby. 😅


  • Man, I haven’t done structural inheritance in years and by now, this reads like the ramblings of a mad person.

    Like, I recently had a use-case, where I actually wanted to define multiple types with the same fields and for various reasons ended up using a macro for that.
    And that still felt simpler than whatever is going on in this article, because there were no cross-relationships between the types at runtime. The macro templated the type definitions as if I had copy-pasted them, except there’s no actual code duplication, which is ultimately all I wanted.



  • The thing to me is always that, yeah, you need a huge commit for a breaking change in an internal library inside a monorepo, but you will still need to do the same work in a polyrepo eventually, too.

    Especially since “eventually” really means “ASAP” here. Without going through the breaking change, you can’t benefit from non-breaking changes either and the complexity of your codebase increases the longer you defer the upgrade, because different parts of your application have different behavior then. So, even in a polyrepo, you ideally upgrade all library consumers right away, like you’re forced to in a monorepo.


  • A few years ago, I set up a home-server with music and some pictures on there, and recently I noticed that my storage disk was getting full. Then I saw that the disk only had 16 GB and wondered, where the hell I got that small of a disk from.

    So, I go to plug in a bigger disk and can’t even find the original disk at first. Turns out my whole storage capacity was one of these bad boys:

    Spoiler

    A tiny USB-A stick, designed for keeping it plugged into a laptop at all times.

    And yeah, I’ve got about 1800 songs, clocking in at 5.8 GB, so even that tiny storage would easily be enough for a much larger collection.
    And I do also have them replicated on my phone, for listening on the go. (Don’t even need an SD card in my case.)