I think what Apple is pushing for is computing efficiency. It still gets faster but with much less power. Focusing on performance solely would be the wrong way to evaluate these chips.
https://www.tomsguide.com/news/apple-m3-chip
There's a reason they didn't just stick an A series chip in their laptops and call it a day - they want more performance even if it comes at the cost of efficiency. It's probably better to say that Apple is pushing performance within a relatively restricted power envelope.
Just to illustrate my point - if m3 had exactly the same performance as m1, but with 1/2 the power draw, I don't think many people would have been happy even if it would have been an amazing increase in computing efficiency.
This drives me crazy. Apple plays the market like Nintendo. Pick something that no one cares about, do it better than anyone else, and make a big deal about it.
I dream of a world where instead of a marketing company becoming a top 3 tech company, a tech company would have. Wonder what they would have done for their laptop...
Or maybe this is just an inevitable outcome of capitalism/human biology where a veblen goods company will become a top player in a market.
So Apple is the most successful company because they prioritize things that no one cares about?
I dunno, if a there was marketing company that could design the likes of the M series chips along with the mobile versions, develop a full technology stack from programming language and compiler, custom chips, through to shipping whole devices at unimaginable scale would make me wonder what technology companies were doing.
What other “tech” company really compares from a hardware perspective? Samsung? Dell? AMD? Love them or hate them, there’s no denying that Apple has serious technical chops. One day people will only hate Apple for reasonable things, today’s not that day apparently.
Apple develops its own OS.
Apple develops its own development stack, frameworks, etc.
Apple develops its own CPU/GPU architecture.
Apple develops its own battery architecture.
Apple develops its own tooling to manufacture a lot of their products.
Apple develops its own tooling to dispose off their products.
There are very few companies that have as much first party Tech in their products from start to finish.
I think Apple under prioritizes sdvanced functionality but if they’re not a Tech company than it’s hard to see what is.
Who knows... maybe they will be like Google (which I consider a tech/engineering driven org) and they'll throw away (good) products all the time just "because"?
I think Apple plays the "niche" very well, not only regarding marketing, but also from a techs view.
What a weird take. Literally every "tech" company is chasing Apple's silicon but you are trying to claim that they're not a tech company. Let me guess, iPhones and iPads aren't tech either, right?
Considering that Apple has been significantly more innovative (tech wise) than pretty all of their competitors I’m not quite sure what this tells about them.
Not really . Or rather not only. The only two things I hate about Apple’s hardware is the lack of repairability and the price gouging for memory/storage upgrades. Otherwise they are objectively miles ahead of their competition
Of course I have no idea why am I taking the effort to respond to an edgy single word comment…
BASH is like Obi Wan. It isn’t the most powerful or flashiest, but it survived a long time, where others didn’t, for very good reasons. Bash runs basically everywhere. It has many modern features you wouldn’t expect. Its syntax is literally what you would type on the command line if you were diagnosing or fixing systems so you don’t need to transpile to another language. Its reliance on other programs means it is glue and can easily incorporate highly cohesive functionality/tools others write and maintain. Also, it’s been around and is everywhere so you don’t worry about trying to incorporate the current latest and greatest declarative tool (which will blow over in 5 years) into your other workflows. Basically, don’t disparage a Jedi/tool that has survived where others didn’t. There is a reason.
Also, use shellcheck. Incorporate it into you editor. Fix all warning and don’t ignore them. This will push you deep into bash syntax rabbit holes but you come out better the other side.
A lot of bash errors are not understanding possible cases due to white space.. which shellcheck catches. After using it for a while, I don’t even really worry about white space because of the good habits I’ve learned/(been forced to use).
I didn't even know that Windows supported that, but I try to keep away from it as much as possible. Makes for an interesting test of scripts, I suppose. Sometimes, I script BASH to cope with any any filenames, but it depends on the usage as a lot of the time you can guarantee that files will be at least semi-sensible.
The style issue shellcheck reports here is probably what we both suspect it is.
The call to echo has a likely purpose is to trim some spaces from a string, but it's not at all obvious why this is done or what the benefit is. In the best case, it leaves the reader pondering this weird semi-no-op.
If you think shellcheck, and probably most readers, is wrong in this assertion, just speak your mind and let's learn from one another. But I certainly can't guess your intention here.
Using "echo" at all is a problem. It's recommended to switch to "printf" instead as echo has unfixable problems, especially with strings that start with a dash.
Not a problem until the random string starts with a dash and you get unexpected results from "echo" interpreting it as an option instead of an argument. Using "printf" bypasses that issue as it's clear what the argument is.
Just tested it and ShellCheck is happy with the printf version:
It's also got a stylistic improvement (in my opinion, anyhow) in that the line feed is explicit in the printf command rather than being almost a side effect of echo.
Edit: I see your point about the "tr" not enabling a dash, so my example falls a bit flat, but my point stands in other scenarios. It's good practise to avoid echo where feasible. I think the double quotes will also protect in this instance. The problem with relying on the tr string to not foul up echo is that you may later adapt the code and use a different translate string which could then introduce a tricky bug to track down.
I'd also add that in the cases where you disagree with shellcheck (it doesn't get everything correct all the time), you can include a disabling comment just before the line to tell shellcheck that you know best:
Yet, medicines of similar structure and minor substitutions all have very similar profile, otherwise they would not havve been unified in different classes (say, benzodiazepines).
Totally agree. This is just cutting in places they’ve probably wanted to cut for a while. They’ll hire back in a year or two as things ramp up, and on projects they consider important.
Agree on the economic approach and with a preference for cap and trade. Create a certain amount of emission billets and auction them off. Then restrict the amount each bullet allows over time. It has economics, planning and reductions all in one.
Even cap&trade is unnecessary complexity. Just tax it. Keep increasing the tax until the pollution levels drop. Use the tax revenue to offset the taxes on productive behavior.
Cap & Trade (as I understand it) would be the government playing referrer, and polluters/cleaners building a market place to exchange credits.
Taxing would involve playing referrer, collecting taxes for this specific issue, and then allocating that tax to either public or private parties to work on productive behavior.
Taxing sounds more problematic given how dysfunctional most governments are, especially when it comes to non-regulatory procedures. More failure points in the market generation.
A variable tax to disincentivize pollution combined with cap and trade would make the most sense to me.
It seems to me the complexity argument works in favor of cap-and-trade. While the global climate and global economy are both staggeringly complex systems, we can predict the former significantly more accurately than the latter. Thus it would be simpler to set the allowable emissions by policy and let the market work out the economic side.
We don't need to predict it. We tax the pollution at its source, then measure the results. Adjust the tax up and down to achieve the desired result. (This is done in engineering all the time, it's called a feedback circuit.)
Not needing to figure out the relationship between input and output is the beauty of feedback systems, and why they are so prevalent in engineering.
For example, one of my jobs at Boeing was working on the hydraulic actuators that moved the elevators up and down. The goal was to move the elevators in proportion to the control column movements. Nobody ever bothered to figure out how far the actuator would move for a particular input. How it worked was a mechanical linkage provided feedback so when the elevator was too far, the linkage would open the valve to move it back. If it wasn't far enough, the linkage would open the valve the other way, which would move it forward.
It behaves beautifully. It also makes the 3 redundant actuators work together, despite variations in tolerances.
Eg. "The tax per gram of PM2.5 is $1. Each year, if average PM2.5 levels across America are above 5 ug/m^3, the tax will increase 10%. Otherwise, it will decrease 10%."
Then lawmakers once need to put in place the tax and set the target, and they never need to intervene again.
If someone is flooding the area around them with high PM2.5 thus that everyone nearby has respiratory problems, but the overall rate of PM2.5 across all of the US is very low (because generally, it actually is) then your proposed scheme would ensure that areas (generally cities) are going to be completely unlivable, but there'd be no reason to change because overall the tax would remain low.
In fact they'd have no reason to improve anything provided that their projection for the cost of improvement looked marginally more expensive then just paying projected future cost of the tax.
Agile is to Lenin as Agile processes are to Stalin.
Read the Agile Manifesto. That’s what Agile is. All else is either:
- (good) trying to implement the Agile Manifesto, or
- (bad) trying to make current process appear like Agile.
Mine cuts off at 35F and I have to manually switch on the oil. I live where winter is normally below 35 at night. Very annoying system. (I didn’t pick it)
FYI, there were zero radiation deaths from Fukishima, although there were ~2200 from the evacuation. Keep in mind this was during the aftermath of a tsunami.
I think there was a lot of hard work that went into to prevention of anything worse happening at Fukushima. At least that is what I remember from reading the iaea report a couple of years ago. I remember it being a very good and interesting read: https://www-pub.iaea.org/MTCD/Publications/PDF/Pub1710-Repor...
The stage of testing is important here. Early on, I agree with the author. Catch code/config bugs early with no wiggle room for retries. But later, testing in a live system that lives with unreliability, you need those configs that allow for it. This enters the chaos testing phase, where you can assume with some degree that the code works deterministically, but now you have to test how it works in non-deterministic settings. Or more likely, why it failed in retrospect and how it recovered previously. This is much harder.
