kikoreis

I think "[automated] disassembly" has a different implication than reverse-engineering; the latter usually involves more depth in the analysis of the binary, usually including more semantic-level considerations (i.e. this block is meant to do this, or this function is used from these different callsites). The best examples of this type of analysis seem to exist in the security community when going into the detail of zero-days, exploits, etc. I think LLMs either already can or will soon enter that space.

"danger abstraction too high, big brain type system code become astral projection of platonic generic turing model of computation into code base"

Given my history I'm definitely not a fan of this madness in the licensing space. But I am also willing to acknowledge that the 1P vs 3P bomb set off by the public cloud incumbents will continue to yield damage to the open source startup ecosystem until something changes.

That's fixable via browser.urlbar.trimURLs: https://support.mozilla.org/en-US/questions/881261

I'm as perplexed as the dog

Well, the reason Linus could confidently choose to license the kernel as GPLv2 is exactly because it inherited no incompatibly-licensed code.

USL v. BSDi (also 1992 — what a year!) is evidence of how non-trivial this actually is: https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....

Ah, it seems that Raspbian built for ARMv6 but still used the ABI tag "armhf", how confusing; I guess Alpine has done something similar.

https://wiki.debian.org/RaspberryPi#Raspberry_Pi_OS_.28forme...

FWIW, the Raspberry Pi 1B is an ARM11, which is why you are getting and booting an ARMv6 kernel. v6 is the architecture; the "l" at the end of "v6l" indicates it's little endian.

As for "armhf" it is a description of the the ABI, and the "hf" means what you said, that the hardware supports floating point operations. I'm slightly confused as to how armhf could work on the ARM11 on the Pi 1 and Zero generations, as AFAICR it targeted v7 onwards.

For those curious about what's going on (the post was removed) they merged with TWS: https://your.online/press-release/

this is absolutely stunning

> Simultaneously, they don’t use a virtual machine or a container, which means you are actually running closer to the metal than any other form of cloud computing I’m aware of.

Because it's positioning a key benefit, I have a lot of issues with this sentence. First, there are many bare metal cloud options (ranging from machine types to full-blown providers). Second, a container doesn't put you any further away from the bare metal than a process.

I thought it was just me!!!

Yes? No? Maybe?

- https://www.vanityfair.com/news/2016/08/peter-thiel-wants-to...

- https://techcrunch.com/2017/06/14/no-peter-thiel-is-not-harv...

- https://gizmodo.com/someone-is-trying-to-discredit-the-story...

- https://www.independent.co.uk/tech/peter-thiel-vampire-donal...

But what would regular people use to play these DVDs?

But don't fractional shares eliminate this limitation?

I'd just ask for a change at MSFT; they have a really good reputation for finding the right position for solid performers. I'm surprised you didn't mention whether you explored that in your post, so maybe you have already, but it's what I'd put all energy into.

Poulsbo, that brings back memories. https://www.phoronix.com/scan.php?page=news_item&px=MTMyODA

How does that analogy work? Isn't metric used by over 90% (well.. [*]) of the world's population?

[*] https://www.reddit.com/r/theydidthemath/comments/2cjiau/self...

Here's a Foxconn factory near Jundiaí: https://goo.gl/maps/Y4R5VzZeS3cqi49W7 They also have other factories in the country, including in Manaus.

It was inaugurated in 2012 and indeed for a few years did produce Apple devices, specifically iPads, but AFAIK in 2017 they shut down the line: https://diariodonordeste.verdesmares.com.br/negocios/apple-e...

Only if the write is buffered, right?

Yeah. It might be a reference to "electronic"; this usually describes the transition from electromag and crossbar to fully digital switching: https://en.wikipedia.org/wiki/Electronic_switching_system

I believe it's actually called Gurupa, and named after the island on the Amazon just downriver of the delta. The only place I know that refers to the area as Garupa is Selfridge's survey at https://www.history.navy.mil/research/library/online-reading... — and even so inconsistently.

Yes, but let's be fair, it's a galaxy better than writing it on a post-it or password booklet, and still way better than using a memorable passphrase which will get reused and then leaked.

Besides, you can encrypt the local storage with a master password (and if you accept online as a requirement, you could even add 2FA to that).

+1000. Let this become a worldwide trend!

Any system which takes more than 1 bit of input (I'm thinking of the top-two runoff system we have in Brazil, but hopefully the analogy is understandable) will generate a result with much higher fidelity. And, who knows, once we get there, we can try progressively shifting the focus of the election from candidates to their policies, which would help remove the most perverse incentives in the system.

OH!

It misses the most important one-liner for python debugging:

  import pdb; pdb.set_trace()

which leaves you in the debugger at a specific point in your code. When I actually did Python dev rare was the day I didn't crack that out!

I'm not sure how refresh.metered behaves when there is a network device change, but I assume it will, yes.

And I'm pretty sure NM lets you set all network connections metered, i.e.

  nmcli connection modify $CONNECTION connection.metered yes

See https://unix.stackexchange.com/questions/364927/networkmanag...

OK, I've had breakfast.

First, has anybody actually been fired for criticizing snaps? Your comment seems to imply through hyperbole that we don't debate inside Canonical, but in my experience that simply isn't true. In fact, I've seen a lot more intense IC to CEO debate in Canonical than anywhere else I've worked. It's not always super constructive debate, but I don't know how much better it is in any relatively small organization with the broad impact Canonical has.

Second, debate and reflexion is how these positions get refined. An idea starts out crazy and radical -- "let's make an OS which costs zero and which anybody on the planet can figure out how to use!", or "Launchpad will only support bzr", or yet again "upstart, not systemd" -- but over time it evolves towards a place of greater consensus. So I don't think we're the destination for snaps; in fact, if these blog posts are only coming out now, it signals we are rather early in the journey.

Finally, I can understand creating a throwaway account to disclose something you're not comfortable with at your workplace, but it's not cool -- nor constructive, civil or all sorts of C words -- to create one to and start with "you're simply not telling the truth". C'mon, I'm your coworker.

Ubuntu does stand for a certain set of values; security built in and doing The Right Thing on the behalf of the end user are part of it. That does lead to certain distro semantics that I'm sure not everyone will like. And that's OK, we do appreciate that some people want to control more deeply what happens in the distro.

There is a whole other set of users that would prefer that Ubuntu kept out of their way administrative actions for which they trust the machine to handle. They are probably more silent because they are mostly OK with how things work. And I'll say that I'm not comfortable with everything about snaps so it's more of a spectrum than binary acceptance.

Snaps were invented because we had a problem. We wanted to make it easier for software publishers -- think games, desktop tools, browsers -- to deliver their software to Ubuntu users, but debs were both too hard and too powerful to make that a viable proposition. In the old days, people relied on archive.canonical.com [1] from which debs like skype were published, but it was unsustainable and led to poorly packaged and out of date software.

Regarding third parties, in the end, nobody in the community reads through the source code of every patch applied to binaries in their systems. There is a degree of assumed trust in any update. I accept that trusting Canonical is one thing and trusting third party publishers is another, but given the motivation I describe in the previous paragraph, the decision to use snaps wasn't made in a vaccuum.

[1] Which still exists, if you want to go and check out the pool for third-party binaries. All of those installed as root!

Hmm, let me think a bit about how to respond to your first paragraph.

But meanwhile, I'm curious about point 3 as you seem to have facts that I lack -- when a confined snap refresh runs through snapd, is the upgrade payload not executed entirely in userspace within the sandbox? I haven't looked at the code, but my understanding of the model is that the snap can only modify its own writable areas (and do stuff like add a symlink to /snap/bin, though that's also limited). So a snap update could't, for instance, modify arbitrary files, nor read restricted ones. Whereas a dpkg install can do anything as root. Can you help clarify?