mpartel

17 ms·

91.
by mpartel 8y ago
This could be really useful for game development! Certain kinds of networked games are built as a model, deterministically updated by clock ticks and commands from the server, and a view layer on top of that. And even model-level objects of
92.
by mpartel 8y ago
Well this sucks a lot, but if I'm reading this right, they at least amended it to be _slightly_ less awful: https://juliareda.eu/wp-content/uploads/2018/09/Copyright_Se... It seems to contain a bunc
93.
by mpartel 8y ago
Please write in your own words, and preferably from your own e-mail address! I can't see getting a bazillion of copies of the same message being anything but annoying and I wouldn't be surprised if they block the sender of such to
94.
by mpartel 8y ago
It's not quite that clear cut IMO. E.g. "intel-microcode-legacy" and "intel-microcode" would be more diplomatic (disgustingly so IMO). And one could argue that every package in non-free would deserve a "-legall
95.
by mpartel 8y ago
Good thing we still have a somewhat anonymous internet. I'd be surprised if there wasn't a benchmark or two on the HN front page by tomorrow. Might even come from a media organization if their lawyers deem this sufficiently unlike
96.
by mpartel 8y ago
My guess is Intel will revert the license change soon. It's just too absurd to stay. But if not, I wonder if distros could have two packages, named with appropriate and well-deserved passive-aggressiveness, e.g.: intel-microcode-insecu
97.
by mpartel 8y ago
Performance is not the only benefit. You also get freedom from data races, and (arguably) the borrow checker imposes structure that makes the program easier to read and reason about, because it's clearer who "owns" (and can m
98.
by mpartel 8y ago
A massive difference in the amount of censorship, for one. Arguably (very arguably), US and EU censorship is somewhat justified by the attempt to protect individuals, but Chinese censorship is pretty blatantly about protecting existing powe
99.
by mpartel 8y ago
Ah, I meant to reply specifically to the command line flags use case. For most other uses of globals, I fully agree.
100.
by mpartel 8y ago
In general I fully agree, YAGNI and all that, but from experience, mutable globals, unless used very sparingly, rigidify the codebase to a surprising degree and make it more error-prone, often for very little actual gain. As with any soft
101.
by mpartel 8y ago
I'd rather readers of such code take the (IMO minor) extra effort to consider the possibility of the worlds being different rather than bake the assumption that they're the same into even more code. That's how globals spread
102.
by mpartel 8y ago
You're right, assuming the module is not too large. There's another point in favor of instance variables: it gives you the flexibility of multiple values in different parts of your code. As codebases grow, the danger of two unrela
103.
by mpartel 8y ago
What if you, one day, want multiple worlds for some reason? I'm developing a game in Unity, and the programming culture around it encourages globals and singletons to an unhealthy degree. I pushed back against them heavily in our proje
104.
by mpartel 8y ago
Mutable instance variables are much less bad because their scope is much more limited: you can much more easily scan all the code that mutates them and check that invariants are upheld etc. Global mutable variables are also awful for multit
105.
by mpartel 8y ago
The only (relatively minor) downsides I can see are: (A) it makes the code "singleton" by default: you can't instantiate two objects of the same class with two different values for the global argument (B) unless the global ar
106.
by mpartel 8y ago
Without an IDE, discoverability is not great even in implicitless code. In `x.y.z()`, you don't need to import the type of `y`, much less the method `z`. And an IDE's "go to definition" works fine on extension methods. I
107.
by mpartel 8y ago
In your example, not really, but in general, assuming the implicit is in scope most of the time, `x.method` is much more discoverable through autocomplete than `method(x)`. Incidentally, the fact that Haskell's function calls look like
108.
by mpartel 8y ago
For others that didn't notice this new and somewhat less expensive version come out, here's the HN thread from 2 months ago: https://news.ycombinator.com/item?id=17124593
109.
by mpartel 8y ago
The truth does not care but human opinions tend to be biased towards extremes.
110.
by mpartel 8y ago
I found "The list of reference capabilities" at https://tutorial.ponylang.org/capabilities/reference-capabil... especially interesting to compare with Rust's borrow checker.
111.
by mpartel 8y ago
For the remote third party case, the option to unlock should be isolated from the OS so that it needs physical access (boot to bios/recovery mode). AIUI that's how it's typically implemented in Androids and in Secure Boot. Th
112.
by mpartel 8y ago
That's fair, and those numbers for rooting are a bit higher than I expected. There's the caveat that rooting and complete OS replacement are somewhat different topics, but those stats are still relevant. So clearly there's a
113.
by mpartel 8y ago
If a significant number of Android security breaches indeed happen through misleading a user into unlocking their bootloader, that would be a convincing statistic to me. But I'm under the impression that that is exceedingly rare and th
114.
by mpartel 8y ago
Bootloader lockdown was practically unheard of for the PC/laptop form factor before Microsoft started doing it for ARM laptops. And and it's not even really standard for phones. Plenty of Android phones have unlockable bootloaders
115.
by mpartel 8y ago
OK, let me be more accurate: "user-openable" in the sense that the user is free to choose to trust any OS vendor they want. What's the unmitigatable harm?
116.
by mpartel 8y ago
If I knew that to be the end-game and if I knew it to be an informed choice on the part of consumers, yes, I'd be OK with that. My two reservations: 1. I think such a lockdown is a kind of hidden anti-competitive "dark pattern&quo
117.
by mpartel 8y ago
That's why I'm entirely OK with making it scary and a little difficult. And it's not just IT professionals, but also their friends and family, especially those that can't afford to or don't want to get a new device
118.
by mpartel 8y ago
I admit I may be ignorant, but could you spell out the security benefits of going from "locked down but user-openable" to "not user-openable"? (edit: specifically benefits that couldn't be effectively addressed by m
119.
by mpartel 8y ago
I don't see the tradeoff honestly. Sure, make it a little difficult, show a big red scary warning, perhaps even require the use of a screwdriver to discourage "casual" users from being misled into compromising their machine&#
120.
by mpartel 8y ago
Like iOS yes, and some, but not all, Android manufacturers/phones. "Others do it too" is not a very good justification in my mind.

More ›