oxplot

> if an user has to go through all that many trouble and risks to preform such simple and (rare but) routine task, this design is bad

You're assuming an Apple user is meant to service their own product. That's not the case as far as Apple is concerned. You have an issue, you drop by the Apple store (or send your device in) and they repair it for you.

Determining good-ness or bad-ness of a design has to take into account the intended usage and design goals. Whether a customer should be able to repair their device easily/at all, is a whole separate topic. Apple doesn't think so and their design decisions have clearly reflected that over the decades. As far as that goes, whether the end user has to dig through 20 layers of hardware before cleaning a fan is irrelevant. What's relevant is whether Apple employees who'll be fixing/cleaning these devices will be wasting too much time for the most frequent support requests. That's what Apple should be (and most certainly is) optimizing for.

Also note that the majority of the end users will not have the time nor the interest to repair their own devices, especially when in most cases, their repair is covered under warranty. A lot of people with the technical skills far more than needed to to the self repair fall into this category as well. I've been modding and hacking expensive hardware for decades mostly for fun, but also for practical reasons, in order to add to/modify behavior of the hardware. Even I have little interest to repair my Apple products I have paid premium dollars on. I increasingly value where I spend my time and I let Apple do my laundry for me.

I must also mention (given the high degree of Apple/Google/Facebook/... bashing on HN) that Apple is among the better, if not the best, manufacturers in terms of warranty service and support (at least where I live). I have requested warranty services for dozens of products and not once have had to "prove" my case, or so much as try to convince Apple of an issue. Compared to every other worse interaction with other brands, I will continue to pay top dollars for Apple products even at the cost of whatever the hot Apple knocking topic of the day is. Having said that, there are of course tools that I need full access and repairability as a given and I never go with Apple in those cases.

EDIT: need a break for sure

This tool takes care of multiple page PDF. You edit one page at a time but you can edit multiple pages of a PDF just fine and save it altogether.

Essentially, the only difference from a purpose built tool is that you jump around between Inkscape and the main window for each page editing.

> A biased survey that mostly pro golang people would take anyway

ok - I was gonna run some BigQuery and get you stats - but that comment makes it clear as day that you're not interested in "proof".

Thanks for saving me time and good luck to you and your Java/C#.

> Except those didn't really manifest.

And your proof is?

> golang is worse for large teams and maintainability compared to languages like Java and C#

How do you figure that? I see large projects like Kubernetes and Docker thriving with contributions.

> Which ended up complicating end users' code.

Some users, sure. Majority of projects, as evident in Go annual surveys clearly shows they are doing OK without it.

> ended up with a weak language

Looks strong to me!

> Approaching 50 here, and no major issues dealing with project deliveries across Java, C#, JavaScript, TypeScript, C++, Transact SQL, PL/SQL, PowerShell, bash

Very commendable — I don't touch JS that I didn't write. Forget C++ altogether :D

I didn't mean my comment as a negative — in fact, I see all those attributes as essential so one doesn't produce junk at a fast rate just cause s/he can code for 20 hour straight and refactor endlessly. Of course I know devs older than me who are still in mass production mode and don't deliberate much. In fact, I often have to ask people to slow down and seek simpler and lazier solutions for their sake and mine further down the line.

> If you consider the US a hostile regulatory environment for cars, then don't innovate there.

Most other western countries are alike (or worse). Except, US is where the energy, best capitalism and talent is so despite the above, probably still the best choice.

> I'm glad the FCC, EPA, NHTSA exist, for all their flaws.

Of course you do, as a consumer. It's only until you want to make something that isn't already made for the past few decades that you start disliking, hating and outright wanting them to just get the heck out of your way. Regulation in itself isn't a problem, its ever increasing and rarely ever decreasing amount that is the issue. There are many rules and regulation that haven't been updated for decades.

> If they're getting a lot of flak, it's because they've earned it.

I guess so, but I think in a different way. Only if they talked more about how much attention they pay to safety of people when they roll out beta to more users and add features, then perhaps the general public would be more understanding. I know about it from obscure tweets and fleeting mentions having watched countless hours of Tesla people talking about FSD, but you really have to dig to hear about it.

Thanks for refs.

> people not clever enough to deal with programming languages.

Add older folks to this cohort. They've lost steam, are lazier and less patient with obstacles and less fortunate with time.

> Tesla just did that by firing the employee in question

I think that was a mistake. Taking away the beta privileges would have been sufficient.

> blurred the line b/w normal business operation and politics by disabling FSD

You're way down playing the impact of the kind of mindset that the average joe has about FSD Beta as portrayed in mainstream media. It's so hostile, emotionally charged and void of any evidence of actual danger, that it pushes the bias needle against Tesla to the breaking point. If your blood sweat and tear is being pummeled around the clock, you get into politics in a blink and double down with whatever you can muster.

Those who think Tesla is just in it for the money, well, there is no conversation to be had with them. They'll catch up. But if one actually believes in what Tesla claims to exist for, then it doesn't take a lot of thinking to see they're right in pushing back aggressively as they do.

> potential

That's the keyword here. It looks dangerous to some, but evidently, no one's hurt yet, driver or pedestrain. And we're talking 60K people with FSD Beta as of Jan (perhaps getting close to 100K around now). At 100K, and average 1000 miles, over 3-6month period, you have 100 million miles driven without a single injury let alone fatality. US average is 1.1 death per 100 million miles. If you don't look at these numbers and just go with the news, it sounds like Teslas are running over people GTA style.

> Why is it out there to begin with?

Because that turns out to be the only way so far to massively train the AIs to move this tech forward. If you think Waymo or any other self driving companies out there are gonna get anywhere with the amount of data they have, you need to get in the weeds a little and see what's what.

I'm in full support of people pointing out issues with tech (not so much with the press writing 10 page articles based on a tweet though). I'm also understanding of Tesla's position. We gotta call it what it really is — bad press. Dan O’Dowd of Dawn project put up a full page ad recently pooping all over Tesla. Guess where the evidence came from: FSD Beta videos on youtube. One has to essentially not care one bit to be OK with these videos if they run Tesla and hope to innovate in such a hostile industry and regulatory environment.

No one who has access to FSD Beta, is in any shape or form mistaken, to think that Tesla is under any obligation to keep providing the feature whether the driver has a safety score of 100 or not. Tesla clearly states in their terms, before you can turn FSD Beta on, that they reserve the right to take it away at any time for any reason and rightly so.

Our great HN community here throws rocks at Tesla and FSD Beta any chance they get. Why in the world would Tesla allow someone whom they employ, to generate bad press while they're still heavily developing a tech. Isn't FSD Beta already not enough negatively covered?

As for firing the employee, WTF Tesla?

> What, exactly, was gained here to justify the productivity lost while waiting?

The goal isn't to wait long enough to come up with something novel. That's what research projects are for, and Go is on the exact opposite of the spectrum. If after deliberation, it turns out that a mostly similar solution is the way to go, then that's doing it "right".

Also, the lost productivity that keeps getting mentioned is overblown. The minority who actually need it (a subset of those who ask for it) are, well, a minority but a loud one. I have developed in Go for 8 years. I only ever reached for generics twice and in both cases, copy pasting the implementation in different types added a insignificant effort.

> Go is a very boring language in a sense that there's very little new there

You hit it on the nail! It's boring. That's what you need when you're targeting large distributed teams and want your code base to survive decades and still be readable and navigatable by pros and amateurs alike. You don't want clever or smart. You don't want cutting edge and novel for novelty's sake. You don't want magic. You don't want to have to keep the context of 20 files in your head to understand one line of code. You don't want a syntax that can be interpreted in 10 different ways in different contexts, ... . You want the sweet spot between simple and practical.

Back to:

> Most critics of Go are well aware of its history and purported design goals.

Your comment about Go being boring and its lack of novel features, is clearly demonstrating that you've either missed or misunderstood the design goals. And many similar comments on other parts of the language from others I've interacted with is what I was basing my parent reply on.

When you hear most critics of Go (or any language for that matter), they talk as if Go is merely an alternative syntax for their favorite language. Of course they're bothered by lack of a missing features and unfamiliar ways. As tired of an analogy as it may be, programming languages are like natural languages. Trying to learn Japanese by translating sentences, idioms and proverbs from English word for word will only end in frustration and confusion.

If you read the history of Go, the whole point behind its creation (as with many others) was to start with a clean slate so new norms and ways of doing things could form, in service of large distributed teams and long term maintainability. Lack of generics, as unrelated as it may seem, is actually the result of the those and other goals. Specifically, Go authors avoided complicating the language, runtime, and compiler early on and thereby avoided negatively affecting long term maintainability of both the language and the code written for it (v1 compatibility promise) before having a good grasp of how generics should be implemented in this new language or if it should be at all. Copying the so called tried and tested implementations from existing languages would make little sense as generics are so intertwined with the rest of a language.

TL;DR approach learning programming languages like you would approach learning a new natural language with the purpose of living among its native speakers.

The archive.ph / archive.is links never load for me. I just learned that it's blocked in Australia: https://en.wikipedia.org/wiki/Archive.today#Australia

Interestingly, only my landline broadband connection blocks them (Aussie Broadband), not my mobile provider (Telstra, Optus)!

EDIT: contacted Aussie since it looks like they've forgotten to unblock it.

EDIT: Not related to blocking - turns out archive.today returns invalid IP when queries by Cloudflare DNS resolvers (which I use): https://en.wikipedia.org/wiki/EDNS_Client_Subnet#Controversy...

Complexity is going to inevitably make everything harder to repair as it becomes ever so involved to learn and understand how things work.

However, it need not be harder than it should be if manufacturers are not hostile towards 3rd part repair. That’s job of the government to mandate it. Most manufacturers want control over their processes to ensure, in the least, the repair is done right and it won’t end up as bad press and reputation damage due to someone else’s screw ups.

EVs are in their infancy. So don’t expect perfection just yet. Give it a few decades and regulation will catch up.

A response I often get is how "refreshing" it is to speak with someone who doesn't spew out fluff and gets to the point. And these are people who themselves ping-pong for 10 minutes before getting to the meat of a conversation.

This is a good example that what people do isn't necessarily what they appreciate or like. It's just a norm. Whether it's positive or not is quite a different aspect.

Re inexperienced users : you want to encourage them to learn and build confidence. Ignoring their "polite" ping-pong messaging isn't going to do them any good. Sure, don't be a jerk, but do mention "don't ask to ask - just ask" in a friendly way.

Holy wow — mine's 7 years old and I thought it was crazy.

I still have the pacman logs from the first package installed. It has traveled to three different machines, three filesystems (ext4, btrfs, xfs), two boot loaders (grub, efi) and two desktop envs (gnome2, mate+compiz).

I really can't imagine using anything else. AUR along with simplicity of the package source format and cleanliness of everything in general, makes this the perfect OS for a pragmalist like myself.

One avenue which doesn't require a lot of people/companies to participate, is carbon capture. Not only can it reduce the net emission, but it can even reverse the trend. One example is SpaceX which has plans to produce some of its methane fuel for starship by carbon capture using solar.

My Archlinux installer [1] uses fyne and I found it to be quite easy and straightforward to use. My use case is quite trivial though so not sure how that scales.

[1]: https://github.com/oxplot/raspberrypi-archlinux-installer

There seems to be a POC that attempts to load dynamically linked libraries on linux (and elsewhere on windows) without CGO: https://github.com/golang/go/issues/18296#issuecomment-46847...

I have read countless counter points to that (and some supporting it). Doesn't look that clear cut.

Weird ha? Get stressed:

- Get a full on 80 hr/week job

- Swim in cold water

- Do HIIT - e.g. run like a lion is chasing you for a minute every day

- Watch horror films

- Drink coffee

- Have sex

If you improve CPU performance, you can compress memory with the leftover cycles. This is what I do on my RPi which allows me to run quite a few memory hungry processes at the cost of some CPU (which is fine, because those processes are mostly idle).

Hmm, no mention of GNU Parallel — that's my go-to replacement for xargs. It has numerous options to treat input as blocks of text, lines, etc and can even run in a distributed fashion over SSH.

Deadlines: perfectionism isn't an issue in itself, spending eternity achieving it, is. Pick a milestone (e.g. MVP of feature X) and a due date. Once you hit that milestone promptly, pick another and repeat.

On a different note, perfectionism can be a symptom of procrastination. It requires much less will power to fine tune an existing thing, than it is to start something new or work through early steps. If this is the case, then apply the usual anti-procrastination techniques: vow to put X minutes a day into a project in order to make it a habit and get the ball rolling; identify obstacles that are creating friction; re-think the design and simplify; breakdown the task to make it less intimidating; etc.

The key to curb bad habits is to create friction, and doing so well in advance. When you're exhausted and you're out of will, you're not gonna take much action to avoid quick pleasures. As it pertains to websites and app, here are a bunch of techniques for creating friction:

- iOS and Android both have screen time features to show you a banner when you've used an app for longer than a set time. This is a good soft block to start with.

- Auto logout after a set time. Having to login is one extra step that may deter you from accessing a website. This can be done with browser extensions.

- Auto delete apps after a set time (this is possible with MDMs). Again, having to install an app would be a big hurdle next time you want to sit back and scroll through clips.

- Throttle speed of a website - this one's a little brittle as you can quickly switch to a faster network, usually your mobile connection.

> Here’s a paraphrased conversation I’m having way to often, costing me way too much time, keeping me from doing things that are way more important.

Then don't have it! Set things up such that only after someone pays, you get notified.