ogre_codes

We used this about 10 years ago and it worked... ok. The problem as some have pointed out already is it’s using a very out-of-date HTML/ JS engine. If you want to turn some HTML reports into PDFs, it’ll do the job.

But there are ways to do this same thing with Puppeteer which uses a modern version of headless Chrome. It’s pretty straight forward and there are easy to chase down documents on how to do it.

Gnome looks a bit like you got stuck in an alternative reality where MacOS evolved slightly differently.

KDE looks like you got stuck in an alternative reality and Windows 7 evolved differently. (And Windows 8/10 never happened)

I never really cared for the Windows UI.

Well for starters, there are lines of cargo ships outside of LA, 20-30 off the coast of LA right now. Typically it would be 1-2. That’s something like 100,000 sitting idle right there. Then many of the storage facilities are also jam packed with containers too.

Apparently we’ve all gone on a spending spree during COVID so more containers are simply out there filled with crap we’ve ordered and waiting for shipment, unloading, and return to the ports.

I don’t use Adobe, so for me, the big culprit has always been MS Office and I’ve been able to mostly avoid it for years. I’m looking more at Slack, VSCode, and other “Essential” apps which have displaced Mac Native tools like BBEdit and if you squint hard, Adium.

Unfortunately, it feels like everything is turning into what Linux was 10 years ago. MacOS is better, but the increasing dominance of Electron and Java apps which bring their own UIs into whatever eco-system they encounter is very frustrating. If you are stuck running MS apps on the Mac, they are their own micro-cosm as well.

Looking and feeling better than Windows is a low bar. Or at least it was a low bar in the Gnome 3.0 days.

I was mostly stricken with how much many of the features they are highlighting look straight out of stuff which was unveiled in MacOS about 5+ years ago. Extensive gesture support being a biggie.

You need to check your dates.

MacOS’s fundamental look has a pretty consistent chain all the way back to NextOS in the 90s. The Dock, the dot indicator, and many other core pieces are visible in versions of MacOS which predate the launch of webOS. MacOS borrows some bits from webOS as well, but the fundamental Dock layout is right out of NextStep.

Been a few years since I’ve used Gnome, I hadn’t realized they’d pivoted so much to following MacOS.

It looks like they’ve taken a lot of the best parts of MacOS and built something really nice atop it.

Pesticides are the more recent threat, but their numbers were hit pretty hard prior to DDT by hunting. Congress put a stop to that in the 40s. Farmers saw them as a threat to livestock.

I don’t use Substack, but what you say matches my understanding of the service. Substack isn’t a brand consumers look for or trust, it’s a brand authors look for and trust. If you are an author, it is a platform which you can build your brand atop. Substack is the platform where you can monetize that readership.

It’s not too difficult to get a Linux VM running on top of MacOS on the M1. Then you can do whatever you want on your M1 Mac and have a full Linux distribution in another window.

Call of Duty is a whole other problem.

Ah, obv I misunderstood your above post.

Makes a ton of sense. It’s been a while since I used Docker, but I’ll have to try it out next time I’m using a container setup. Particularly since HyperKit seems to make running a VM so straight forward.

If having a specific version of a tool is important for your work, it’s probably best to install that tool separate from homebrew and manage that install separately. The Postgres docs seem to recommend the EDB installer.

https://www.postgresql.org/download/macosx/

Likewise Python and other programming tools where running a specific version is important are best managed outside homebrew.

The big thing Docker solves is repeatability and isolation. If you create a Docker instance on your Mac, you are more or less guaranteed it will work the same in production.

If you were to create a Linux VM to replace Docker, you would need it to also recreate the Docker build tools for that VM so you could recreate that VM on the server. At that point, you’ve more or less come full circle and essentially recreated Docker.

Give me a break.

The M1 migration is less than a year old and it’s already the single best/ most successful CPU migration in my memory. Far better than Apple’s PPC -> Intel Migration and massively better than whatever half-steps Microsoft has done to port over to ARM.

Apple absolutely should invest in much of what you suggest. In 6-12 months, after the platform is complete and mature enough to identify where the big problems are.

Most of us understand that you exercise caution when migrating mission critical work onto a 6 month old platform.

In the mean time, Apple has been hiring top Docker talent like Michael Crosby.

https://www.protocol.com/apple-hires-cloud-open-source-engin...

It’s possible they are hiring top container developers just to improve their internal cloud infrastructure. But what kind of hardware do you expect these guys will be running?

EDIT: Trimemd some repetitive stuff.

Absolutely. Should have been more clear it was preference.

> ... all those shiny (and that's a compliment) pieces of hardware become heated vacuum cleaners.

> I'm not saying "lol, Mac is teh suck"

Biggest eye-roll post of the day. Literally one sentence after the other you suggest Macs are worthless and that you aren't saying they suck.

> Running Docker on native Linux machine is vastly superior

I don't know about "Vastly", but it is better and will likely always be better because of the structure of Docker. Docker is by definition, a container that runs atop Linux. Since Linux is already Linux and the Mac has to run Linux in a hypervisor, bare metal Linux is almost always going to be faster.

But, Docker is just a part of the workflow. Dealing with the limits of the Linux Desktop to get better Docker isn't worth it a lot of the time.

Since Docker only runs on Linux, it's always going to be faster/ better on Linux. On the Mac you have to run Linux in a hypervisor, then run Docker on that instance. Things can get a better, but it's always going to be a bit of an alien.

I have the 8GB MBA I bought for my wife and feel somewhat similarly. There are a few times when things lag a bit, but mostly it just hums along.

I'm holding out for the next gen to release for my personal machine and will go with 16GB and whatever the next CPU is. Mostly, as you suggest future proofing, but there are a few spots in my workflow where it does hang a bit which I think extra memory would help with.

This brings back memories of slowly dying car alarms back in the 90s.

I probably come across as being more anti-solar roof than I am. Mostly just feel like this isn’t a feature I’d make a purchase decision on and wouldn’t likely pay too much for.

I was reading on the Tesla forums about just bringing a portable solar array for camping and it’s weirdly a lot more complicated than you’d think. Perhaps having it integrated would make it simpler, but it’s a lot trickier than just topping off a 12v battery with a solar array.

How many places are you going to restart this same well trod argument?

I wouldn’t say anything except this is twice you’ve brought this up out of the blue under one thread that I’ve seen and this isn’t even talking about the Apple ecosystem.

I can understand why you would need to drive 3 miles instead of ride a bike. Your first reply covered that quite well.

The rest of this gibberish. I have no idea how you see this as a reasonable interpretation to either of my posts.

My point was that if it’s feasible to walk or ride a bike someone instead of drive, you should. I didn’t make it well, but I also didn’t suggest you are better driving 10 times further either.

You’ve gone from making a reasonable point to being damned near incoherent.

> I don't see how I'm blowing that out of proportion?

Above, you gave (to me at least) the impression that you were referring to all of Librem’s revenue. Not just the revenue which is filtered through the App Store, every penny they earn.

I don’t care for a lot of the way the App Store works, including the point you make here. But your original post was not very clear if this is what you meant to say.

There should be room in the App Stores for businesses which sell services where the App is only part of the offering.

> Arguing these fine points is a waste of time because I feel like people defending this are missing the complete insanity of this situation

All I’m suggesting is we just discuss what Apple actually does rather than exaggerating it to poorly make a point.

> That's a deflection tactic, and doesn't justify anything. 15% is still too much as long as there are no alternatives.

I wouldn’t have even mentioned this if you hadn’t blown the first more important point out of proportion.

There is an absolutely massive difference between “All their revenue” and “All revenue from in app purchases”.

Can already do this on the Tesla. It’s not solar, but cracking the windows and running the fans to keep it vented isn’t going to burn more than a mile or two of range.

The best way to spend money improving an EV is almost always going to be on batteries or weight reduction. Self charging is neat, but unless you get much more efficient solar arrays, it’s always going to be limited to niche applications. Five miles more range is always going to be useful, solar arrays which add a mile or two of range under specific conditions are far less interesting.

You have a banking subscription?

> Yet Apple is forcing them to give up 30% of their revenue, because they can.

This is a bit disingenuous. Apple isn’t forcing them to give up 30% of their revenue, they are requiring they give users the option to sign up through the App Store.

If most of their customers come from outside the App Store, this won’t make much difference to them.

If they make less the $1m through the App Store, it will only be 15%.

The second is a bit of a niggle, but if most of their promotion and value comes from outside the App Store, this wouldn’t be a big problem.

> I feel like it's really lame that its Swift version 157 or whatever and they still don't have a stable async/concurrency story besides callbacks.

It is frustrating, but it seems like they are finally getting there. It’s frustrating since a language like Go had a good concurrency model almost from the start. But Go had different constraints and arguably has less surface area to cover.

> It seems like you'd always want to use actors?

My impression is that when working with Swift your first tool of choice should be a value type, so a strict or an enum. Actors would only be desirable when you need class-like behaviors and need concurrency. Maybe I’m missing something, but I suspect many of us will never use actors directly at all. I certainly don’t see any parts of my code which demand this kind of structure.