Ubuntu is doing stupid things with packages, replacing them with their proprietary packaging system (called Snap). It has been controversial, the way that they are pushing it, especially since the Snap server is proprietary and non-open source.

A lot of people won’t consider using Ubuntu at all for this reason alone, and it makes sense - when you consider that there are so many other distros to choose from these days, Ubuntu just doesn’t really provide a whole lot of added value anymore.

There are a lot of other helpful replies in this thread, so I won’t add much, but I did find this reference, which you could read if you have a lot of free time. But I particularly liked reading this summary:

• _start calls the libc __libc_start_main;
• __libc_start_main calls the executable __libc_csu_init (statically-linked part of the libc);
• __libc_csu_init calls the executable constructors (and other initialisatios);
• __libc_start_main calls the executable main();
• __libc_start_main calls the executable exit().

Reserving main is definitely more hacky. Try compiling multiple objects with main defined into a single binary - it won’t go well. This can make a lot of testing libraries rather convoluted, since some want to write their own main while others want you to write it because require all kinds of macros or whatever.

On the other hand, if __name__ == "__main__" very gracefully supports having multiple entrypoints in a single module as well as derivative libraries.

Is it? I really don’t think so. What can you propose that’s better? I think if __name__ == __main__ works perfectly fine and can’t really think of anything that would be better.

And you don’t have to use it either if you don’t want to anyway, so no, I don’t think it’s that much of a hack. Especially when the comic compares C as an example, which makes no sense to me whatsoever.

Can you put some milk on the algorithm please?

B-b-b-but my convenience!!!

Of course you can. Instead of committing the code to a repository, you just take screenshots of the everything and commit that instead.

Milk has always grossed me out for weird reasons. Reading comments like this makes me glad for that.

And for anyone that has some kind of gross facts about oat milk, I DON’T WANT TO KNOW ABOUT IT THANKS!!!

But was this a reversion of the previous commit…?

When is the last time anything Microsoft made was an upgrade…? Word 97??

I’ve never had the chance to use a functional language in my work, but I have tried to use principles like these.

Once I had a particularly badly written Python codebase. It had all kinds of duplicated logic and data all over the place. I was asked to add an algorithm to it. So I just found the point where my algorithm had to go, figured out what input data I needed and what output data I had to return, and then wrote all the algorithm’s logic in one clean, side effect-free module. All the complicated processing and logic was performed internally without side effects, and it did not have to interact at all with the larger codebase as a whole. It made understanding what I had to do much easier and relieved the burden of having to know what was going on outside.

These are the things functional languages teach you to do: to define boundaries, and do sane things inside those boundaries. Everything else that’s going on outside is someone else’s problem.

I’m not saying that functional programming is the only way you can learn something like this, but what made it click for me is understanding how Haskell provides the IO monad, but recommends that you keep that functionality at as high of a level as possible while keeping the lower level internals pure and functional.

This is the thing UI designers never understand[0] - if you keep changing shit around, nobody will ever figure out how to use it. If you keep it consistent and don’t make dramatic changes, users will have a much easier time using it because they don’t have to keep relearning the damn thing. Consistency is the most effective UI paradigm.

[0] or to put it in better terms, they’re paid to not understand this so they can justify their jobs…

Can we push back the deadline for the apocalypse? Have we talked to the customer to see if this is a possibility?

Looks like there’s been plenty of recent updates to me: https://github.com/void-linux/void-packages/commits/master/

Today, management learns about the Streissand Effect.

MOBILE USERS CAN GO FUCK THEMSELVES.

Phew. That felt good.

The difference is how you interact with the browser engine. Blink is very easy to embed into a new browser project. I’ve seen it done - if you’re familiar with the tools, you can build a whole new browser built around the Blink engine in a few hours. You can write pretty much whatever you want around it and it doesn’t really change how you interact with the engine, which also makes updates very simple to do.

With Firefox, it’s practically impossible to build a new browser around Gecko. The “forks” that you see are mostly just reskins that change a few settings here and there. They still follow upstream Firefox very closely and cannot diverge too much from it because it would be a huge maintenance burden.

Pale Moon and Waterfox are closer to forks of Firefox than Librewolf for example, but they’ve had to maintain the engine themselves and keep up with standards and from what I’ve read, they’re struggling pretty hard to do so. Not a problem that Blink-based browsers have to deal with because it’s pretty easy and straightforward to update and embed the engine without having to rewrite your whole browser.

Unfortunately, since Google controls the engine, this means that they can control the extensions that are allowed to plug into it. If you don’t have the hooks to properly support an extension (ie. ublock), then you can’t really implement it… unless you want to take on the burden of maintaining that forked engine again.

That said, Webkit is still open source and developed actively (to the best of my knowledge - I could be completely wrong here). Why don’t forks build around Webkit instead of Blink? Not really sure to be honest.

I chuckled a bit while reading this, because what you wrote is exactly where Blink came from. It was a fork of webkit, which in turn was derived from KHTML. Then again, the fact KHTML was discontinued does support your point to an extent too, I guess.

But the point is, Chrome is doing exactly this - providing the engine free as in beer and letting people embed it however they like. And yet, what you’re predicting, ie. not using the original but just using forks instead, doesn’t seem to be happening with Chrome - they still enjoy a massive fraction of the market share. There’s no reason to believe that this couldn’t happen at Mozilla as well. People usually want the original product, and it’s only a small fraction of people that are really interested in using the derivatives.

Ironically, the anti monopoly lawsuit against Google will end this.

People are quick to assume this, and there’s a very good chance that they’re right, but I don’t think we should take it as a given. It’s always possible that there could be some sort of court decision that allows Google to keep funding Mozilla after the “breakup” is complete.

In any case, we don’t yet know what the outcome of the antitrust case will be, so I think it might be best to avoid making statements of certainty like this until we see how things really shake out.

We should definitely take the possibility of this happening very seriously though.

You’re right, but Socraticly speaking, then why are there so many blink-based browsers and so few gecko-based ones? The answer is because blink is easy to embed in a new project and gecko isn’t.

If Mozilla really wants to take back the web (and I honestly don’t think they actually do), then what they should really be doing is making gecko as easy to embed in a new browser as blink is. They don’t do this, and I suspect that they have ulterior motives for doing so, but if they did, I think we would be much closer to breaking chrome’s grasp on the web.

Because let’s face it: Mozilla makes a pretty damn good browser engine. But they don’t really make a compelling browser based off it. Ever noticed how Mozilla has been declining ever since they deprecated XPCOM extensions? It’s because when they provided XPCOM, it enabled users to actually build cool and interesting new features. And now that they’ve taken it away, all innovation in browser development has stagnated (save for the madlads making Vivaldi).

They need to empower others to build the browser that they can’t. That’s what would really resurrect the glory days of Firefox in my opinion.