> It seems odd that self driving cars have been skipping this step.
[Citation needed]
2,022 karma · joined June 2, 2015
dilip@katamari.io
[Citation needed]
I started following freight waves when I was working for an autonomous trucking company. This publication is one that I recommend adding to an RSS feed.
It's a surprisingly complex ecosystem that has deep insight into several facets of global economy. And this publication's coverage of this ecosystem has my vote of support.
David McAlpin made a very strong case for Brahui *not* being a Dravidian language, but rather descended from the proto-elamite language family. He showed how Proto dravidian and Proto-elamite could have descended from the same parent language - he calls this Proto Zagrosian.
It's a very interesting take and I am personally convinced that he's on the right track.
David McAlpin et al have presented compelling evidence that Brahui is a sibling language to Elamite. To me, the most interesting outcome would be finding that Harappan is another lost member of that family.
Let me try.
First up, it is extremely possible that OpenBSD is not for you. If you require something that is Linux specific, or you absolutely need Bluetooth or one of the other few things that you don't get with OpenBSD, and you are unable to refactor your life to not need those things anymore, then OpenBSD is a no go.
If that is not a concern, the strongest argument I can make for OpenBSD is that it's an operating system that wants you to trust it. It's written by people who understand system correctness matters above all else (and security just happens to be a nice side effect). Most of the time, this has only small and subtle user facing effects: good documentation, sensible defaults etc. But it really shows when you use it for a long period of time and see how over and over again, a decision made 10 years ago made OpenBSD somehow immune to the burning zero-day crisis of the day.
I can not help but see this as a malicious change.
Orbot directs all traffic from my phone through the Tor network. If an iPhone is secretly pinging some backend server for telemetry / looking for automatic updates / etc, then all those pings will now happen from the Tor exit node, effectively completely deanonymizing the user.
It's a trivial matter for an adversarial agent to ask apple for lists of all hits from a specifc tor exit node and identifying information from that user, and cross check that against whatever traffic they are trying to deanonymize.
I might be misinformed here, but I would love to be corrected about why anyone should trust Tor enough to access it from an iPhone anymore.
| Non MBA | MBA |
————————-|————————-|————-|
Quadrant | | |
Engineer | ME | |
————————-|————————-|————-|
Not a | | |
Quadrant | | |
Engineer | | |
————————-|————————-|————-|From an outsider’s perspective, it looks like in a 2x2 matrix of developer simplicity/complexity and operational simplicity/complexity, the current patterns all seem to be heavily biased for developer simplicity/operational complexity.
1. Is this assumption correct?
2. Does optimizing for another quadrant: developer complexity / operational simplicity make sense?
My intuition is that complexity in code can be managed far better than complexity in operations. Developers have abstractions, reusable libraries, unit tests/integration tests, etc. There may also be weird efficiencies that arise from having developers deal with some of these problems right from the design stage.
It seems kubernetes takes a problem and pushes it to fully to operations.
Is there a solution that takes this problem and turns it into a developer problem?
It reflects that the mechanism is a way to securely store some identity related information. It is not a mechanism to establish that identity.
The value proposition is still obvious: You need to establish your identity once, and then you can securely save it and share it across devices and avoid having to reestablish your identity every time.
It also removes the “password” confusion entirely. Establishing identity could be through a fingerprint or verifying a government issued Id card in person etc.
The name also correctly reflects what it is doing while still sounding marketable to non technical users. The mental model that a non technical user will build more closely reflects what is actually happening - which is always helpful to build a good user experience.
Consider a shared computer in a university laboratory or at a public library. Or maybe an iPad that is shared by a family.
As a service provider, you usually can not assume that someone using your service will log in with a dedicated device or with a device that has their primary google or apple accounts setup on it. (Some rare exceptions might exist).
I don’t think anyone wants to deal with customer support problems of “oh, I’m stuck in a different country when on a holiday and my phone got stolen, can you please recreate this key exchange process for me on this untrusted device logged in from public wifi at a coffee shop?”
Like with ssh certificates, you create more problems than you solve if you use passkeys as the primary authentication mechanism.
To answer your question, yes it would be primary authentication if you used it that way. But no sane person would. Hopefully.
The biggest mistake that the passkeys movement did is try to make it sound more marketable at the cost of oversimplification.
First up, these aren’t really “no password” mechanisms. They’re closer to ssh certificates. You need to authenticate through some other mechanism and then agree to do the equivalent of creating and installing ssh certificates on your device.
The ssh certificates get synchronized across your devices securely by your cloud provider. But they can never serve as the primary authentication mechanism - that will still have to be a traditional authentication mechanism.
It’s mildly infuriating that someone decided to take this simple idea and confuse the fuck out of everyone by positioning it as some alternative to a password based authentication mechanism. Obviously everyone is going to come and ask a ton of questions about how a mechanism without any passwords should work. And then the responses further confuse everyone because they don’t want to admit “no actually you still need passwords”
/rant
> As a result, we decided to enable cross-device registration of passkeys. That means, you can register a passkey on your phone while you’re using your desktop. The passkey lives in the phone, but users can connect it to their desktop and set-up and authenticate through the desktop’s browser. This enables Linux and Firefox users to set up passkeys.
This has always been the real no-go for me when I was implementing auth.
I looked into supporting passkeys and found that they're basically useless unless you can make some strong guarantees about who/what can access the keys stored on the device. Linux and the various BSDs can not do this today (and likely will ever be able to do this well given that someone can always recompile a malicious OS that pretends to be another well-trusted OS).
If a user needs to reach to their phone to log into something on their laptop - that's never going to be really secure. It's only a matter of time before everyone starts having "We will never ask for you to log in through your phone, don't do this if someone asks you to" warning labels and respawn the entire industry of anti-phishing mechanisms for this new attack vector.
> These tales are the tales of us all, again yet again.
> We are history relived and that is all, without end that is all.
Can you elaborate?
I've seen a couple of malloc implementations, and in all of them, free() is a cheap operation. It usually involves setting a bit somewhere and potentially merging with an adjacent free block if available/appropriate.
malloc() is the expensive call, but I don't see how a GC system can get around the same costs for similar reasons.
What am I missing?
A barista knows when a customer will pay for coffee (after they have placed their order). A barista does not know when that customer will walk in through the door.
> (if you did, there would be no point in using reference counting).
There’s a difference between being able to deduce when the last reference is dropped (for example, by profiling code) and not being able to tell anything about when something will happen.
A particular developer may not know when the last reference to an object is dropped, but they can find out. Nobody can guess when GC will come and take your cycles away.
> The cache misses absolutely demolish performance
With safe Rust, you shouldn’t be able to access memory that has been freed up. So cache misses on memory that has been released is not a problem in a language that prevents use-after-free bugs :)
> If you’re using a language without GC built in, you usually don’t have a choice.
I’m pretty sure the choice of using Rust was made precisely because GC isn’t a thing (in all places that love and use rust that is)
These are not the same.
The problem with GC'd systems is that you don't know when the GC will run and eat up your cpu cycles. It is impossible to determine when the memory will actually be freed in such systems. With ARC, you know exactly when you will release your last reference and that's when the resource is freed up.
In terms of performance, ARC offers massive benefits because the memory that's being dereferenced is already in the cache. It's hard to understate how big of a deal this is. There's a reason people like ARC and stay away from GC when performance actually begins to matter. :)
The reality is that it takes a ton of work to get a microcontroller to blink an LED. Various clocks need to be configured, various peripheral devices (I2C controllers, GPIO controllers etc) need to be configured, interrupt vector tables need to be set up and so on.
Who is expected to do this work?
Today, it is done by the semiconductor vendor. When you buy a microcontroller, you’ll use an SDK and a toolchain that the vendor offers.
The vendor is incentivized to keep their SDK and tool chain as general as possible to sell into as many different designs as possible.
The OEM wants to ship a product as quickly as possible to make their cashflow model work.
There’s a huge gap between these two ends where a ton of important stuff goes unaddressed. At no point are the OEM and semiconductor vendor incentivized to sit together and addresses all the issues that fall through the cracks.
The current school of thought dominating MBA courses would see addressing these issues as a cost with no tangible benefits to the business. I can see their rationale: if consumers don’t signal that they care about security, then it is actually hard to argue that addressing security is a benefit to the business.
Most consumers today don’t know how bad the situation is to care about this stuff. It sucks because we firmware engineers want to do the right thing but we can’t justify it.
I want a solid UNIX ecosystem with power10 to compete with macOS + Arm. I’m tired of there being only one real option for a reliable unix laptop.
1. There is an excess supply of apartments including the ones that have already been sold. The demand side is mostly people buying second and third units as investments.
2. China is going through a weird demographic situation. The younger generations are significantly fewer in number, they will need fewer apartments to live in.
3. Chinese provincial governments raise money by developing land and continue to be incentivized to build/approve/encourage a lot of apartment units.
4. All of this is funded with mortgages.
Thing is, all four of these can not possibly be right. It’s a little too insane. Whoever is on the other side of all those mortgages should have abandoned ship a long time ago otherwise.
What am I missing?
Who is holding all that mortgage debt? Who is continuing to issue more of that debt? When do the number of people selling their investment properties exceed the number of younger generations looking to buy their first primary residence?
What solutions do other practitioners use with FreeBSD? Or do you abandon modern DevOps practices entirely and hold a meeting to determine partition sizes, provision servers to individual services running on specific named computers and plan for a software upgrade for weeks in advance of a deployment?
1. Software supply chains. Our civilization is built on top of a layer of software that has a gaping security hole the size of a gas giant planet. It's also recursive - software dependencies themselves have further dependencies and so on. As we get into a world with autonomous trucks driving down highways at 60mph and cars that collect a complete profile of location data history of unsuspecting drivers and upload them for "analysis", this problem will explode in ways that very few people can even imagine much less predict.
2. Linux distro upgrades. An Ubuntu LTS release or an RHEL release will eventually come to end of life. At that time, performing an upgrade across a fleet of servers is a complete fucking nightmare. You test everything that you know to test, hit deploy and watch as your servers go down and reboot with a new software version and restart various services and containers and hope everything will be ok. This is not sustainable. A solution is needed and is worth $$$.
Can anyone please link me to the announcement? My google-fu is failing me today.
I used to subscribe to The Information. They had really high quality content consistently.
But then they got greedy and introduced an even more expensive plan and moved a bunch of features to that more expensive plan, and what’s left in the lower tier (but still hundreds of $$) subscription is kinda crap.
I’m not sure I want to renew my subscription this year.