368 karma · joined November 12, 2009
https://www.tomn.co.uk/
https://github.com/tomjnixon
Linux doesn't allow anonymous contributions:
https://www.kernel.org/doc/html/latest/process/submitting-pa...
and this guide has been adopted by a lot of GPL-licensed projects (at least openwrt, glibc and gcc).
Given how popular DIY phone battery replacement is, you'd expect there to be at least a few incidents reported if it was a major risk, but I just don't see them. On the other hand london fire brigade reports 200 candle fires a year...
A good analogy is the use of candles. They are pointless and fundamentally dangerous, but some people like them. People who like them even think they are calming, which is a very bad reaction to an open flame from a risk-assessment point-of view.
If i knew my neighbour liked candles, i would hope that they are being safe and accept that they have a right to take socially-acceptable amounts of risk, not berate them on the internet.
I don't see how repairing battery-containing electronics is any different. Both are unnecessary, and both could turn a small mistake into a fire.
So, I'm quite happy replacing my own phone battery with reasonable precautions, but no, friend, you may not charge your sketchy e-bike in my hallway.
The level of risk that is acceptable is socially defined, and far from the black-and-white view that some people seem to have.
> stick with through-hole parts, if at all possible
These days it's more work to avoid SMD than it is to embrace it. Many many parts are not available in through-hole, and dealing with 0805 passives and 0.65mm pitch ICs is not that difficult (unless you assume that it is).
As a bonus, you get much easier re-work, access to assembly services, and cheaper components.
When everything is working right there should be no difference, but when things go wrong, not having plastic stuck to the heat break makes it more likely that a beginner can fix their own problem.
At least where I live, there are landlords who operate reasonably (reasonable rents, with safe and maintained properties, that respond quickly to issues), but there's so much demand relative to supply that it doesn't really affect the ones who are just trying to extract maximum profit.
Source? I didn't find much. Google talk about buying "carbon-free energy", which isn't bad, but ultimately just moves the carbon to other uses. Energy is also not the only resource being wasted.
I also tend to think that the way people talk about energy use of technology is misguided, but ultimately data center energy use does likely form a significant part of my personal carbon footprint, which i care about, so it's quite reasonable to argue against finding new exciting ways to use energy when, to me, the benefits are so often unclear or negative.
> 10 minutes of compute in a datacenter is far more environmentally friendly than 10 hours of work by a human.
I don't think this is a good way of looking at it. Lots of things that a computer can do quickly would take a human much longer, but that doesn't mean they are good uses of resources. A better solution is to do neither, and this applies to a lot of what the article talks about.
There is also a massive amount of competition between the various players, and nobody taking part cares about the energy use (otherwise they wouldn't be doing it), so i don't see this happening.
(rough numbers: a H100 is 700W, which is $613/year at $0.1/kWh, and the estimated cost is $25000-40000)
That's exactly what i was referring to. If you have a commit, that is both a snapshot (as stored in the tree reference) and a change (because it has references to parent commits, which are also snapshots). Of course the wording is factually accurate, but it refers to computing the change, because that's how it is best explained, and how those commands (rebase/cherry-pick/revert) work conceptually.
If you try to understand those commands without thinking about diffs, you can come unstuck.
Commands like reset of course don't talk about changes, because that's not relevant for how they work. Understanding both models and their equivalence is helpful, IMO.
IMO it makes just as much sense either way. When cherry-picking a merge commit you have to specify which parent to diff against, which could just as easily be explained in terms of diffs (i.e. which part of an n-way diff to apply).
> it's easy to develop a wrong mental model of the repository - a model that most people operate on, but which will bite you sooner or later. That's exactly why so many people end up being confused with Git
This doesn't match my experience (as "that guy that people go to for git help"). Perhaps you have a concrete example.
Just to be clear, i'm not advocating for teaching or believing that git works in a way that it doesn't, that would be silly. More that being able to think about it in different (equivalent) ways in different situations is helpful.
By meme, i don't mean that it's wrong, it isn't, just that in my opinion it's a thing that people like to repeat because they have heard others say it. That's my only explanation for why someone would say "at the user interface level, Git stores snapshots" when the interface is, i think clearly, mostly about working with commits as changes.
> You and some others in this comment section are simply wrong about this. Everybody is wrong sometimes, that’s no problem.
About what, exactly? As far as i know, what i wrote is factually accurate (or an opinion, which can not be wrong).
Yes, the git manual writes about snapshots, because it's literally true (and sometimes necessary to understand), but it also repeatedly refers to commits as changes, because that is a helpful and equivalent way to think about commits, modulo some details which mostly don't matter.
Where in the user interface? All the common commands act like they are working with diffs.
It amazes me that people keep repeating this (there's another thread of the same stuff here https://news.ycombinator.com/item?id=38896658#38897488 ). It's like "actually git commits are snapshots not diffs" is such a powerful meme that those who repeat it forget about their day-to-day experience of working with git, in which it tries as hard as possible to hide the snapshots, and let you work with diffs.
The onion really has three layers:
2) In the user interface, all common commands work as if commits store a reference to a parent commit and a diff.
1) Commits actually store a reference to a tree (snapshot) and a parent commit; diffs are generated on-demand.
0) Trees (snapshots) may actually be stored in different ways, where "smallest/fastest/simplest way to create new file from old file" makes sense.
Most people live comfortably on layer two. Occasionally you might need to know about layer 1 to do something weird, and layer 0 is only really for people interested in implementation details.
> Git does delta compression, so in fact it does usually store diffs on disk.
Yep. The comment you replied to originally was pointing out that snapshots and diffs are isomorphic, so i'm glad we all seem to agree.
> What the user actually operates on in the repository are snapshots
They don't, though. Git doesn't show you the tree IDs in normal operation, and you can't actually make commits that point to specific trees (snapshots) without unusual commands.
> it actually goes further and is using three-way merge for better conflict resolution. It works on snapshots, not diffs
It doesn't really matter what it's working on, the best mental model to understand cherry-picking and rebase is that of applying diffs. Can you (in general) even explain things like rebase and cherry-pick without the terminology of diffs? The git manual doesn't bother.
It uses snapshots because that is efficient, but from a user perspective all common git operations look more like they are operating on diffs than snapshots.
When you cherry-pick a commit, the diff of the old and new commit will be similar, but the snapshots are normally completely different; that's the point. The same goes for rebasing, which is like applying a set of patches. Heck, if it goes wrong, you get merge conflicts, which wouldn't happen if you were just manipulating pointers between snapshots.
Git actually makes it quite difficult to manipulate commits as pointers to snapshots instead of diffs -- i doubt most git users even know about `git commit-tree`.
This is why i don't really get the "git is wrong and should work on diffs" crowd. If it did, the user experience would be 99% the same, unless you're manually editing your diffs before committing them.
If you don't want type checking, don't run mypy.
I don't see what's so difficult. If it was technically possible to run programs that have type errors in other languages, they would have the option to ignore type errors too, because it's convenient.
Typescript also ignores errors (generating js output for you to run) by default, so what's the point if it's not enforced?
The fact that the typescript implementation does not run typescript directly, and cPython does not type check before running the code, are both implementation details.
Typescript is just a better type system on top of javascript than python's type system is on top of untyped python, because typescript is a cohesive design rather than a collection or random stuff accumulated over time.
There's no reason that couldn't have happened for python, it just didn't.
You obviously don't get the haskell experience, where if your program type checks it's probably correct, but the alternative (if, remember, you want a dynamically typed scripting language) is no type checking, which is definitely worse for some people.
For me, that's the benefit of typing in python (as shonky as it is) -- you can use it to help write better library code, then ignore the types (except as accurate documentation) when using those libraries.
Maybe there are other languages that can do this, but the ones i know all have their own downsides.
I wouldn't be so sure -- toughness has a specific meaning (energy before fracturing), and polymers are generally going to be tougher than glass.
http://www-materials.eng.cam.ac.uk/mpsite/interactive_charts...
I haven't dug into it, but note how the article mixes up these terms to make it sound better:
> transparent wood came out around three times stronger than transparent plastics like Plexiglass and about 10 times tougher than glass.
If you plot that on those graphs it doesn't put it anywhere remarkable.
edit: This is like trying to sell an electric bike by saying that it's three times faster than walking and 1/10 the price of a car -- ok, but how does it compare to a pedal bike? It's much more obvious when you do it with words that most people understand intuitively.
They also never claimed that what they want is the ideal behaviour for everyone. Wanting a different behaviour from the "good enough, works for most people" solution is perfectly valid, and doesn't necessarily imply that you think the default is bad.
> Generally, people don't care if the phone uses expensive 5x lens or not. I don't really know who does
I'm not sure the author does really. They just want the option to be able to chose to step back to get a higher quality photo. Camera quality is a big selling point for iPhones, so it's not too surprising that some people think their phone should help them take higher quality photos instead of letting them make bad choices.
They said that they want the 5x option to only use the 5x lens, but their bigger complaint is that they can't see what it's doing until too late. I'm sure they would be satisfied with an option to turn on an indicator of which lens is being used, or an unobtrusive message which says "move back 10cm for a better photo".
Heck, the google camera even does this, when prompting you to turn on night sight if it's too dark for the normal mode. That's a very similar trade-off.
> I don't think it's better than other platforms
I think we're done here.
Like what? None of the ones i know of meet the "expressive, flexible and easy to learn as python" test.
> There's this myth that Python as a language is superior to JS. In reality both have their long history and warts. JS/V8 is just much faster.
I never said anything about being better or worse, just that as far as i know there's nothing about JS which makes it much easier to optimise than python.
I'm not arguing that python is the best thing to use for everything, or that there are no faster languages; that clearly isn't the case.
The topic is "why is python popular", you're arguing that it's too slow and it's too much effort to speed up code, while I'm arguing that there are no languages which are faster, and don't give up some of the things that made python popular in the first place.
JS is probably the closest, but not because of superior language design -- people with money wanted it to be faster, so it is.
Also, the choice is not just python, or writing a module in C -- there's numba and cython, various python compilers, pypy and cffi.