Even worse thermal issues than ... a laptop with no thermal issues and a fan that never even seems to audibly turn on?
12,236 karma · joined April 12, 2010
Eh, that's part of it, but a lot of it has to do with the M1 having very very high IPC (much higher than comparable x86-64 parts), meaning they could run the chip at a much lower max clock speed (3.2 GHz versus boosting to 5 GHz for most competitive x86-64 CPUs) for similar overall performance.
This makes a huge difference because power consumption increases exponentially with clock speed.
edit: thinking about how it relates to Intel's process–architecture–optimization, it feels a bit tricky to compare. Apple's process seems to be something like: architecture(A-series chip for iPhones)-optimize-with-new-die-reusing-basic-cores-in-diff-arrangement-targetting-perf-in-small-thermal-envelope(M1 for iPad Pro and small Macbooks)-optimize-again-with-another-new-die-reusing-basic-cores-but-in-yet-another-arrangement-targetting-perf-in-a-wider-thermal-envelope(M1 Pro/Max/Ultra), and that all happens before you get to the next M-series increment, which begins with an A-series increment.
So the M2 is less the optimization of the M1 than it is the re-use of the cores in the new A-series chip preceding it, which was an architectural change, plus optimizations and other SoC differences.
Most of that stuff was a result of their very impressive integrated northbridge, but they never publicly demonstrated any CPU that could actually drive all that bandwidth.
Supposedly they had plans to eventually ship a 16 core processor that would really use all of the I/O bandwidth, but they never manufactured anything more than a 7w, dual core part. The Amiga X1000 only featured a single 1 GigE port.
So it’s not like they sold when they had a revolutionary monster ready to dominate the market sitting in warehouses. They had long-term plans, but they may have been starting to doubt the feasibility of executing them, or being relevant by the time they’d scaled the architecture up to sixteen cores, by the time Apple came along.
Not at all. Pretty much all software at the time was commercial or, at most, shareware. Pre-web, selling binaries to people to run on their computers was just how one made money as a software developer.
That professional tools in particular were fairly expensive software packages (CodeWarrior, a few years later, was several hundred dollars. Power C was dirt cheap at $20) seemed completely normal. A carpenter isn’t handed a full workshop worth of saws and chisels gratis, after all. If I wanted to be paid to make software, just as obviously the professionals who made the compiler did, too.
(it’s really difficult to convey how incredibly good all of the documentation and examples that came with some of these products were, too. Think C (back when symantec sold compilers and wasn’t a fourth-rate antivirus vendor) came with thousands of pages of physical manuals teaching you everything from the fundamentals of programming to exhaustively documenting their libraries, with wall charts of class hierarchies etc. Pre-internet this stuff was worth it’s weight in gold)
This seems like the wrong way to look at it?
Focusing on the spots in your code where you’re using RC and concluding you ought to be using GC misses the fact that all of the spots in your app where you’re getting along fine without GC would suddenly be forced to bear the costs of GC.
And RC isn’t a poor man’s GC; Apple concluded that Automated Reference Counting was a significant memory and CPU win over running a GC. Unless you’re littering RCs literally everywhere, you’re probably not doing anything much worse than ARC does in Swift (in fact you’re probably doing better if you don’t do it anywhere the compiler didn’t force it, because Swift has less lifetime info and is forced to be more defensive) – you’re more than likely coming out ahead versus what your runtime costs of a GC would be.
(But if you’re not concerned about runtime memory or CPU cycle costs at all, then sure, Rust is probably at the wrong level of abstraction for your problem)
Safely parsing untrusted XML is an extremely hairy task.
> Too vague to be useful. Stolen from whom?
Heroku and Travis CI. That information is literally in the end of the sentence you cut off:
"On April 15, we published a blog detailing an attack campaign utilizing stolen OAuth user tokens issued to two third-party GitHub.com integrators, Heroku and Travis CI."
Which is so frustrating. When you upgrade your hashing algorithm, always always _always_ immediately remediate the weak hash mess by hashing your weak hashes with your new stronger hash, and turn the login check into
bcrypt(sha1(user-entered-password)) == stored-bcrypted-sha1
You can.
Right Click -> Open With -> Other... (Always open with checkbox)
is for setting a particular association for the particular file you right-clicked (maybe you always want this file to open in Sublime, but this other one with the same extension in TextEdit, for some reason, etc).
command-I to open the Get Info pane -> expand Open With block -> use dropdown labelled "Use this application to open all documents like this one" -> click Change All... button
is the bulk edit flow
Command-d is still mapped to don't save (at least in Preview, just verified). Escape is cancel.
(AFAIK there's no mass-discard option, but I've never really thought about it before because 99% of the time Preview is showing me something that's already on disk)
Right, but that's kind of missing the author's point, which isn't "things that are written in C are slow" so much as "because C lacks generics and has a relatively-inefficient standard library implementation based on function pointers, most implementations do not take the extra steps of 'using all of C's features' to do something faster (because it's a lot of work, and the standard implementation exists)".
It's mostly just an argument that generic-lacking languages make it easier to do something slower than something faster, and most people and projects follow the path of least resistance. That there are more efficient implementations available if you sink more effort into it isn't in dispute.
It's an engineering decision with tradeoffs, like every engineering decision.
Oh? No? Then why did you write:
> Or they realise the hubris you need to have to think 150$ to be a meaningless amount of money.
What is the hubris if not that there’s somebody, somewhere for whom it’s a lot of money that I failed to add enough disclaimers about for your tastes?
I was clearing talking about $150’s value to me relative to my own personal income, so you clearly felt like that needed to come with some disclaimer about Italian developers, for some reason, despite me living half a planet away from Italy and never having said anything about anyone other than I, myself, and me.
What seems like the real hubris here is yours — your insistence that everybody else’s personal opinion on what’s a lot of money to them personally MUST make space for the chip you have on your shoulder.
> You seem surprised that people don't care about what things mean to you when you communicate whereas it should be obvious. You are not writing for you after all but to be read.
While I am writing to be read, I am expecting an audience that speaks English well enough to understand that “I” and “me” refers to, well, me, and logical and mature enough to understand that a statement written by me and about me quite obviously has nothing whatsoever to do with the income of people halfway across the planet – it’s just spectacularly and completely irrelevant to anything I wrote about how much the cost of the tool impacts me personally.
I seriously doubt that Italian developers consider less than 0.06% of their income “a lot of money” either, for what it’s worth. If you make $50,000, do you consider $30 “a lot of money”? Because that’s the scale of what I’m talking about here.
And sure, $30 is probably still a lot of money to someone somewhere else; but do you also go shout at teenagers in GameStop the next time they refer to a $30 video game as “cheap”? Seems like foolish and irrelevant behaviour, to me. Somebody’s cheap will always be someone else’s expensive.
I’d suggest you learn to read things charitably, instead of searching for the most unlikely and preposterous meaning you can possibly dream up in order to get mad at a post. You’ll be happier for it.
That anybody claiming serverless has "solved all the pain" is definitely trying to sell me something.
It’s a small sum of money for me. It is obviously not a small sum of money for a Bangladeshi beggar or a Peruvian cobbler.
What, exactly, is the point of this complaint? It’s obvious that people are speaking about themselves. Some people in some nations have more money than other people in other nations — that’s the world we live in. We are all already aware of this.
What is useful about bringing this up? Should every discussion of every price of everything in the world have to list how affordable it is in each and every country on earth? Is that your idea of a realistic approach to a discussion?
Because downvoting isn’t discussion, it’s a lazy way of dismissing something instead of taking a real position around whatever it is you disagree with.
> Because you are not writing for yourself but for the HN readership and the HN readership most definitely includes the people you pretend not to be "forgetting" but actually are.
Do you honestly think that “every post must include and add a disclaimer accounting for every possible perspective of every possible reader anywhere on Planet Earth” is a reasonable expectation to have for this, or any, conversation forum?
Should every discussion of, say, Spotify mostly focus on how unaffordable it is the population of Burundi, rather than trusting reasonable readers to understand that people are speaking to their own experiences rather than trying to make universal claims about the entire globe?
I’m seriously asking, because it seems like an absurd expectation to me.
Because to expect the latter is both ridiculous and impossible.
What? There are plenty of free options out there – that’s why they’re not likely to be in the market for a paid tool. It requires an incredibly uncharitable reading to somehow get “students aren’t allowed to merge things” from anything I wrote.
I don’t think every tool needs to be free just because a price-sensitive part of the market exists, and I personally appreciate that there are, for what is a meaninglessly small amount of money for me, options in the market that invest in solving some of the jank that the free options bring with them. But some people aren’t doing this professionally and some people don’t notice the jank and that’s fine too – they aren’t shopping for anything better. I wasn’t either when I was a student. Free was fine enough.
> I don't imagine iron smiths had trouble with expensive anvils either.
I would suggest not looking at getting into blacksmithing, if you want to maintain this belief. Even if you don’t buy one, the raw material and fuel is a far far cry from free.