Alupis

There's an old saying:

The best time to take action was yesterday. The second best time is today.

Tariffs are a long-term economic policy. It will take longer than 365 days to change consumer spending habits and onshore foreign businesses/production and rebuild domestic businesses/production.

Most countries have tariffed US goods for decades. The US tariffs on foreign goods will, over the long term, convince foreign nations to reduce or eliminate their tariffs on US goods (creating a more fair business climate for US businesses), and/or increase domestic production (creating jobs, salaries, taxes, etc).

We can't act like it's just too late to do anything about the lop-sided economic policies of decades-past, and we can't act like changing those policies today is nothing but doom. There will be a restructuring - a period of time to adjust - and then things will be fine over the long term. It just takes time and the political will-power to do so.

For today, sure. People act like 365 days is long enough to change consumer spending habits, and onshore production facilities that took years to offshore.

If tariffs are held strong, there will be two possible outcomes:

1) Domestic production will be increased (via American businesses as well as onshoring foreign businesses), providing jobs and ultimately lower-cost products

2) International tariffs will be decreased across the board - resulting in a more level field for American businesses to compete in foreign nations

Few realize American goods have been tariffed internationally for decades, resulting in a difficult-or-impossible business climate for American businesses.

The situation is akin to Wall Street's infamous short-term outcome favorability. Tariffs are a long-term game, and people have to be willing to trade some short-term outcomes for the long-term economic health of America and it's businesses (and jobs, wages, etc).

Brokerage fees are a business decision. USPS only charges about $5 for dutiable international parcels - and with 15 years in logistics I can confidently say they often don't even charge that fee at all.

Tariffs are designed to change consumer spending habits, and force international businesses to create on-shore operations. To that end, they are effective - but it takes longer than 365 days for those patterns to shift.

> misguided close-the-barn-door-after-the-horse-ran-out policy

> helped install this corrupt administration

I dare say your opinion, here, has nothing to do with the efficacy of tariffs. Tariffs have long been studied, and both major political parties have called for tariffs like we're seeing right now at various points in recent history. The only difference is nobody desired to rock the status quo, so the lopsided economic policies of the past persisted.

Nearly every other nation tariffs American goods in some way. American businesses attempting to sell products into Brazil, the UK, Germany and more are - and have been - at a significant disadvantage for decades due to high import taxes and duties. For the first time those international businesses are feeling the same consequences as their own nation's weaponized economic policies. Perhaps that will put pressure on their governments, achieving the ultimate goal of the USA's policy - reduce and/or remove tariffs across the board. ie. Fair Trade vs. Free Trade.

FedEx has always charged a brokerage fee, that is and has always been ridiculous. The brokerage fee in some cases exceeds the actual taxes and duties.

That is to say there is no 200% tariff on cups.

[1] - https://www.fedex.com/en-us/ancillary-clearance-service.html

I'm reminded, once again, of the recent "vibe coded" OCaml fiasco[1].

The PR author had zero understanding why their entirely LLM-generated contribution was viewed so suspiciously.

The article validates a significant point: it is one thing to have passing tests and be able to produce output that resembles correctness - however it's something entirely different for that output to be good and maintainable.

[1] https://github.com/ocaml/ocaml/pull/14369

Presumably it had access to GCC (and LLVM/Clang) sources in it's training data? All of which are hosted or mirrored on Github.

I can't be the only person seriously questioning the "Budget" page the AI created?[1]

The estimate seems to leave out a lot of factors, including irrigation, machinery, the literal seeds, and more. $800 for a "custom operator" for 7 months - I don't believe it. Leasing 5 acres of farmable land (for presumably a year) for less than $1400... I don't believe it.

The humans behind this experiment are going to get very tired of reading "Oh, you're right..." over and over - and likely end up deeply underwater.

[1] https://proofofcorn.com/budget

If I install podman on my Linux machine, it's rootless by default. No fiddling required of me.

Docker could do a lot better job in the packaging of their software. Even major updates require manual uninstalling and reinstalling it... Podman just works.

That seems incredible. 16GB of ram to run (presumably windows 10) and Eclipse?

Eclipse, unlike IntelliJ offers "project" view were you have have many "solutions" open at once. Even with multiple Eclipse instances open, it's hard to imagine it consuming so much ram.

Perhaps you had other company-required software running. I was working on relatively largeish codebases and very happy with 8GB of ram until 2018ish.

Regardless, an IDE is more than a text editor, so your claim that RustRover with 4.5GB of ram is inefficient is misguided.

Devcontainers[1] or some similar technology are a must. Use whatever specific IDE you want, but the development environment itself should be identical across everyone on the team.

No more "works on my computer" issues. The environment is always identical.

[1] https://containers.dev/

How much ram did you have, and when was this? I remember being extremely happy with Eclipse on an 8GB machine - this was back in the jvm7 days. Heck, I did jvm6 development with Eclipse on Windows XP with 4GB of ram and was content.

Eclipse gets a lot of automatic hate - I believe mostly since a lot of people first use it in university and struggled with their first real IDE.

For years and years I had people telling me how great IntelliJ was, etc. I eventually switched - lo and behold, IntelliJ had just as many quirks (even some of the same) as Eclipse.

In 2020's national election, nearly 87% of California votes were by mail[1].

California offers day-of in-person voting, and has ballot-drop boxes (unmonitored) and drop-off (monitored) locations for at least several weeks (I believe it was a full month in the past election).

[1] https://abc7.com/post/election-2024-21-californias-registere...

A literal "X" is an accepted signature. As-is initials, and printing vs. cursive[1]. A signature is not a way to verify identity.

[1] https://codes.findlaw.com/ca/elections-code/elec-sect-3019/

> The most important feature of public elections is trust.

Agreed.

However, in some states, such as California, mail-in voting has become the default.

What's used to verify identity and integrity? Your signature from your voter's affidavit of registration, a signature from any past voter form, or literally an "X"[1]. Your signature doesn't even need to match, it just must have "similar characteristics". You can print your name or sign in cursive, you can even just use initials. They're all accepted.

We're firmly on the "honor system".

Pair that with lack of voter ID laws, and we have a system that's designed to be untrustworthy.

Yes, I agree, a state issued ID should be free...

[1] https://codes.findlaw.com/ca/elections-code/elec-sect-3019/

Both. Whatever works for you I'd say. I targeted the Raspberry Pi (Cross-Linux From Scratch variant), and a fake root (via chroot) and qemu. This was circa 2014 though.

These days the ARM64 processor on the Raspberry Pi 5 is probably fast enough to just build natively on it, no cross-compilation necessary. Cross-compiling adds a metric ton of complexity.

LFS is a teaching/learning tool. Asking an LLM to generate one for you would be fairly pointless. Just read the book and follow along...

I completed my Cross-Linux From Scratch distro in 2014, targeting the original Raspberry Pi since I was frustrated with the lack of (at the time) minimalist distros.

It was extra-hard, due to the cross-compiling nature of targeting the ARMv6 cpu family - but I learned a massive amount along the way.

Even though CentOS-minimal was released for Raspberry Pi by time I completed the project, I had so much fun it didn't matter. I ended up making a custom build system, consisting of a hodgepodge of bash scripts all wrapped together with a Makefile. My self-hosted Jenkins build server (old mini computer shoved on my book case) would run builds and produce the image artifact - those were the days...

The final distro image was ~40MB, which was impressive to me on it's own.

They do offer a systemd version[1], along with a variety of other versions, including Gaming Linux From Scratch (X11 and Wayland), and Automated Linux From Scratch (with a build system)[2]

[1] https://www.linuxfromscratch.org/lfs/view/stable-systemd/

[2] https://www.linuxfromscratch.org/index.html

I've contributed to Renovate in the past, helping bring new language support.

It was intimidating for me, being my first contribution to such a large-scale, widely-used project - but the team was absolutely wonderful to work with and guided me through the process, including multiple PR's and rounds of reviews.

The Renovate project has served as an example of how I want to structure and operate my own open source projects. On more than one occasion I've checked to see "how does Renovate [the project] handle this?"...

Big shout out to Michael Kriese (viceice)[1], the dude is an absolute machine. I don't know how he does what he does.

Also a huge shout out to Ryhs Arkins (rarkins)[2], creator of Renovate and a man with unlimited patience for my rookie questions.

Lastly, big shout out to HonkingGoose[3] (who's name we may never know), for turning my gibberish into proper documentation. What a legend.

Every one of my new projects uses Renovate. Not having to worry about monitoring dependencies, manually bump them, etc. is a great thing even for small codebases. I only have to deal with dependencies when something fails and Renovate tags me on the PR - pretty cool. I highly recommend checking it out of you have not done so before.

[1] https://github.com/viceice

[2] https://github.com/rarkins

[3] https://github.com/HonkingGoose

Perhaps this is the original PR for the Radio/RadioGroup[1].

It does seem the complexity was a deliberate decision.

[1] https://github.com/radix-ui/primitives/pull/121

I'm reminded of the recent "vibe coded" OCaml fiasco[1].

In particular, the PR author's response to this question:

> Here's my question: why did the files that you submitted name Mark Shinwell as the author?

> > Beats me. AI decided to do so and I didn't question it.

The same author submitted a similar PR to Julia as well. Both were closed in-part due to the significant maintenance burden these entirely LLM-written PR's would create.

> This humongous amount of code is hard to review, and very lightly tested. (You are only testing that basic functionality works.) Inevitably the code will be full of problems, and we (the maintainers of the compiler) will have to pay the cost of fixing them. But maintaining large pieces of plausible-in-general-but-weird-in-the-details code is a large burden.

Setting aside the significant volume of code being committed at once (13K+ lines in the OCaml example), the maintainers would have to review code even the PR author didn't review - and would likely fall into the same trap many of us have found ourselves in while reviewing LLM-generated code... "Am I an idiot or is this code broken? I must be missing something obvious..." (followed by wasted time and effort).

The PR author even admitted they know little about compilers - making them unqualified to review the LLM-generated code.

[1] https://github.com/ocaml/ocaml/pull/14369

When you use frameworks or libraries, you are trusting (hoping) the author(s) spent the time to get it right. At a minimum, the framework/library is documented in literal documentation and/or code that's static and can be read and understood by you. Ask an LLM to do a task 3 times, you'll get 3 different outputs - they're non-deterministic.

I catch a lot of nonsensical and inefficient code when I have that "back and forth" described above - particularly when it comes to architectural decisions. An agent producing hundreds or thousands of lines of code, and making architectural decisions all in one-go will mean catching those problems will be vastly more challenging or impossible.

I've also found reviewing LLM generated code to be much more difficult and grueling than reviewing my own or another human's code. It's just a mental/brain drain. I've wasted so many hours wondering if I'm just dumb and missing something or not-understanding some code - only to later realize the LLM was on the fritz. Having little or no previous context to understand the code creates a "standing at the foot of Mt. Everest" feeling constantly, over and over.

I've found that "back and forth" is part of the learning aspect LLM's provide. Even when the LLM provides code snippets, I type them out myself, which I've found forces me to think and understand them - often finding flaws and poor assumptions along the way.

Letting an LLM drive in an agentic flow removes you from the equation. Maybe that's what some want - but I've personally found I end up with something that doesn't feel like I wrote it.

Now... get off my lawn!

Are they? Not a single one of the other public clouds runs Windows at it's core...

As far as deployed operating systems go, Windows is in the extreme minority.

Over 60% of customer workloads running on Azure are Linux. And that statistic is skewed by those using things like AzureAD (basically workgroups).

At some point it will become a burden to develop new technologies on Windows instead of Linux. If that hasn't already happened.

Desktop already is a dwindling revenue stream for Microsoft. Microsoft is already pushing for companies, from small garage startups to mega enterprises, to migrate to online services where the underlying OS doesn't matter.

Windows has inertia, a lot of it. But all things in motion eventually come to rest.

Nothing in the linux world would forbid something like Group Policy. A commercial distro that targets large-scale enterprise customers could implement something exactly like Active Directory + friends.

Ansible, FreeIPA, and more can be used individually or together to achieve what AD provides. There are large enterprises that are non-windows...

None of the software and services you mentioned require Windows though - they could be made to run on Linux, and some already do.

As more and more revenue shifts from desktop/servers to cloud and services, it doesn't seem too far-fetched for Microsoft to decide maintaining the entire OS stack themselves makes less and less sense. A Microsoft Windows linux distro would free up resources to focus on what makes Windows unique.

My only issue with Material-anything is it immediately looks/feels to me like something Google-related.

Not a deal-breaker entirely, but for my own things I like differentiate.

It is, however, unfortunate that a single statement on the Gleam homepage generates this exact conversation every time Gleam trends somewhere.

It's your project, and your community, of course, and I fully respect that. However it doesn't seem good that this statement creates so much friction and controversy for Gleam over and over.

After all, none of the statement's topics would be "on-topic" for any of the Gleam community hangouts. For instance, it would be equally off-topic for someone to discuss supporting or hating Nazis.

Perhaps moving the statement to a formal Code of Conduct page would be a "have cake and eat it too" type thing.

The Gleam community is wonderful, and you've done an incredible job building it. But I don't suspect the homepage statement had anything to do with that.

Well, North and South America are two different tectonic plates[1].

[1] https://www.usgs.gov/media/images/tectonic-plates-earth