> Having been given an android work phone, I can’t understand why anyone would use this willingly.
This is probably a commercial Android distro like Samsung's or Google's, filled with OEM crapware. Pure Android is far better than that and is free (freedom to install apps, inspect the source code, etc.) It's basically a Linux distro for smart phones.
It’s crap, sorry. It’s an inconsistent mess. Having come from iOS it’s as clear as night and day.
It doesn’t really matter to me if there’s some other specific version of Android that fixes some issues if I install it. As a user that’s not something I care about.
> Having come from iOS it’s as clear as night and day.
It's odd because, as someone who daily drives a Pixel with GrapheneOS and also owns an iPhone, my experience is the opposite. You could not pay be to go back to a device controlled by a corporation, and on which I am not allowed to run programs without Apple's blessing. The UI is largely a matter of taste, by now all mobile operating systems have converged to a broadly identical design and similar gestures etc.
The most desirable outcome with iPhones is to be able to run an up to date fully-patched iOS on them with up to date apps for as long as the device will function.
The next most desirable outcome is to be able to run another solid/secure/up-to-date mobile OS on them, and it gets more relatively desirable once iOS stops supporting the device.
Given they found a secret key in a public place? No that’s not malicious and it would be odd for a serious organisation to be upset someone immediately invalidated it.
Are you really unable to imagine a situation where financial or physical harm is caused by a system abruptly being shut down by a credential revocation, triggered by a random person on the internet?
Other options available: ruin the company financially, violate the terms of service of whatever system it uses and get the organisation banned, access business/customer data.
If it’s that sensitive and there’s access keys accessible to anyone, it could end up much worse. Nobody said it was without inconvenience.
This is so stupid. It’s pretty simple: malicious actors will use it to do all of those, plus now they can unilaterally bring down a system via revocation.
Non-malicious actors using it to bring down a system via revocation are therefore indistinguishable from malicious actors. It’s by definition a malicious act.
That’s why it’s a stupid idea. Non-malicious actors should just contact the company and let them take action. It’s not for an outsider to decide the impact of a leak.
Could you point to the part where I said revocation as a principle is a bad idea? Rather than what I actually said, which was that untraceable random third parties revoking your keys without any involvement likely isn’t a good idea.
Also GitHub doesn’t revoke the keys. The providers of the key take provider-specific actions, which may or may not be revocation.
That’s your opinion and plenty of people in here have pointed out they disagree. It has nothing to do with people not being serious or being unable to envision a situation where it impacts an important system.
Is that system made by a supervillain or a mad scientist? But such system can go amok for any reason. Anyway revocation is already possible by publication on github, telling to GPT or sending an email to webmaster.
The alternative is that the key won't be quarantined and the attacker will be able to do everything. And quarantine still means denial of some service, e.g. ec2:StartInstances is denied, but ec2:StopInstances is allowed? So the attacker can shut down the system and you won't be able to start it again?
Can you point me to where I said I had an alternative? Or any rules that say you can’t discuss an ideas flaws if you don’t immediately have an alternative?
The status quo is clearly the local minima, given the myriad of trade offs and different parties involved.
Not any more than any other public endpoint service exposes.
This revocation endpoint can be protected by auth too. Use API key that you're revoking in auth.
I see now from another comment you thought about denial of service for service that leaked key. And I thought about mass leak resulting in DDOS onto API provider. Wrong guess from me.
[1] gives different numbers. About 3x decrease in industrial energy consumption since 1970. Steel production decrease is about 3x ([2]). Chemical production has shifted from bulk production to pharmaceuticals.
That’s a different metric - “million tonnes of oil equivalent”. That’s not the same as electricity consumption - that’s the total amount of energy used in all kinds of industrial processes.
Dont think this is the right way of looking at it.
Two things were happening at the same time: deindustrialization and electrification. Industries and the economy used to depend more on machines and oil. That was getting replaced by reliance on electricity. If electricity generation was cheap enough, we might have seen the total energy usage get transformed one for one into electricity usage. But that didn’t happen and energy usage overall went down. That’s deindustrialization.
Of course it could have other reasons like labour costs and so on.
The data across the board supports the notion that reduction in electricity is an industrial phenomenon overall, there is no data to suggest this is a 'consumer green activity' phenom - not even the link you provided.
All of think links here, the person you are responding to, mine (above) and your own directly point towards reduction in industrial use.
No, literally the evidence you provided does not support the 50/50 thesis, moreover, the data does show that residential reduction is a marginal - and you're probably failing to take into consideration the UK has grown by more than 10M people during that period aka this is 'per capita' - not aggregate.
This government data is must more substantial than that link, and it puts the ratio at 70% reduction in electricity due to deindustrialization.
Moreover - the OP's comment was a blatant misrepresentation (lie) - by ignoring deindustrialization, the primary factor as stated in the article (and in reality) - plus a bit of a thrown slander aka the 'Telegaph-esque' nonsense.
Interesting - I had never associated the rate of energy consumption with jingoism, but based on some of the comments here it clearly is.
I guess it’s sort of a “I drive a large inefficient car and that’s a good thing” kind of situation? Excessive unnecessary production and consumption is a positive trait?
Standard of life and energy consumption are clearly correlated, though in the long-term improved efficiency makes this hard to evaluate.
The fact is, the UK has undergone a nearly complete deindustrialization in that period. e.g 'cars made per capita' is about 1/3 what it was. Domestic white goods are gone. Commercial shipbuilding is gone. Consumer electronics is gone. Domestic textiles are gone. Steel smelting (and nearly recycling) and machine tools are gone. For centuries(decades) these things were quintessentially British.
Certainly doesn't help that AI datacenters use energy consumption as a stand-in for scale, so now the "line must go up" market growth psychology is spreading into power consumption overall as a bigger = better thing.
Oh, I think you're so right. I heard ton of people online assuming that Rust could help to catch any freaking bug, and when they noticed that - well, it obviously doesn't - ah, then it's just crap or hype.
The linked thread here[1] is… illuminating. The Zig stdlib seems pretty buggy, and the much applauded IO interfaces seem to be struggling with cancellation. The BDFL doesn’t seem to have much to say other than “brush your teeth”
No, that's not the best description. The Io interface is actually one of the best cancellation stories out there. If you combine it with defer/errdefer, you get safer cancellation guarantees than you have in async Rust (you can do async "drop" for example). The only problematic part is the interaction between the Reader/Writer interface and the Io interface, with regards to error handling.
> The only problematic part is the interaction between the Reader/Writer interface and the Io interface, with regards to error handling.
The fact that error handling suffers when combining two of the base interfaces of the standard library is pretty rough though? I don't think rust has that particular problem.
It's a different approach to Rust. There, if you cancel a future, it stops polling and runs the Drop interface. You don't get to do more complex cleanup. But, at the same time, because cancellation is not an error that all functions have to propagate, it's structurally not possible to ignore it. Zig, like many other languages, uses a specific error to indicate cancellation. The application can decide what to do with it, it has some benefits. But unlike Python/Java where exceptions can he thrown from anywhere, Zig errors need to be named and that's where to issues comes from, because the Reader/Writer interfaces no longer are generic, they can't pass the concrete errors returned from the implementations, and cancellation is one of the errors that get hidden that way. It's a comprise either way, Zig would need to have first class support for comptime interfaces/traits to solve it better, but that's not going to happen. So in the meantime, there is a dilema how to handle it, but I'm sure it will get solved, or at least best practices will get developed.
I am not really convinced that new best practices will be developed or in included in the standard library because andrew thinks that there isn't an issue.
I have a partially written blog post in my head, as I've spent a lot of time thinking about the problem. I'd have preferred if there was a change to the reader/writer interfaces, but even without it, I'm starting to see patterns that work and can be applied to any code to make it safe. People just need to be aware of the problem and that's my goal, although I'm probably failing if my tone is creating the drama, so I'm learning how to communicate it better.
I don't think you are creating any drama to be honest. I understand how frustrating it must be.
There is a similar issue in kotlin where a cancellation is marked via a CancellationException but that extends IllegalStateException and thus Exception. Because of that it gets caught and swallowed all the time. This is a constant source of bugs for me at work and google has resorted to a bunch of linting to get around this design mistake.
Unfortunately, it you want to handle errors right, it's overly verbose, so no one really does it. That's my problem really. Even in the blog post snippet, I could have show well behaved code, because I'm well aware of it, but then the error handling would be more code than the part I'm trying to showcase. Static analysis will not help there.
Cancellation in Rust is problematic too but for other reasons than cancellation in Zig is problematic. Maybe there is just no free lunch here, but hopefully it can be fixed in Zig and Rust.
Not a zig person, but the post you linked has a good counter example on why the proposal for adding cancellation to the interface is bad: You would be forcing cancellation semantics on interfaces that might not want nor be able to provide one. Forcing a new method because the libraries are not well designed does not seem right for me. Maybe another solutions is available, but that is not one.
I get the pain, but the answer from Scott Redig totally makes sense. I am not sure what is worse: Libraries swallowing cancelled() or libraries lying that they support cancelled.
The point is libraries are agnostic. You as a library user provide io transport and loop implementation which supports/not supports cancelation. And you as as library user handle cancelation.
> Libraries swallowing cancelled() or libraries lying that they support cancelled.
I think it entirely depends of what censorship you care about. If political censorship is irrelevant to you and puritanistic and copyright censorship is what's in you way then western search engines are more heavily censored.
This. Google like ChatGPT have started censoring content like people did not populate this earth by fornication. Yandex cares much less about this sort of censorship, at least from what I can tell. Even Bing fell from its throne. IYKYK.
The desirable outcome for most people doesn’t seem to be the ability to run android on an iPhone, let’s put it that way.
reply