Hacker Newsnew | past | comments | ask | show | jobs | submit | cyberax's commentslogin

Same here.

For years, I resisted even using an external monitor, preferring to work on my laptop's monitor instead. I finally switched to using a monitor when poor posture started getting uncomfortable.

I almost always have just one window on the screen, maximized. I'm also using virtual desktops to switch between the browser/app and the IDE. This kind of setup really helps me with the focus, but at the same time it's not too annoying.

I used to just use the macOS virtual desktops, but with the Apple Silicon transition, they also added annoyingly slow animation for desktop switching. That can not be turned off (seriously, wtf, Apple?). I jumped to FlashSpace the second I found about it.


Another point: do NOT use the "~" or "^" versions for automatic updates. Just lock everything tight in your package files. Then have an alert on the lockfile changes.

> The H1B i140 petition thing requires you to advertise the job before submitting the petition.

You're confusing things. I-140 is a green card application, not H1B.

H1B petition requires the I-129 form and an LCA from the DoL. No advertisement is required, except posting the LCAs in a conspicuous place in the company office.


Iraq is pretty flat on the routes between the US-allied countries and the major strongholds (Basra, Baghdad). You can't easily conceal rocket launchers there.

Tehran is protected by mountain ranges that can provide plenty of cover. And Russia is probably feeding it the real-time radar data from its military bases in Armenia.


On the other hand, _all_ the WiFi devices that I had at some point fell off the network, at least once. Including doorbells and cameras. While PoE devices just work.

Another point is that mains power in my area can go down periodically. My PoE switch is powered by a Li-Ion UPS and can provide power for about a day.


> My PoE switch is powered by a Li-Ion UPS and can provide power for about a day.

Same - and i can "remote yank" the power, thus restart the devices without lifting a finger (much).


> On the other hand, _all_ the WiFi devices that I had at some point fell off the network, at least once. Including doorbells and cameras. While PoE devices just work.

I've not had that in a decade, and only for really shitty devices. I've also had crappy PoE devices stop working, ports blow. Too much effort to be worth the bother for me nowadays. If I had to bet my life sure I'd probably use wired ethernet. But if I had to bet my life I wouldn't be using PoE for power either.

UPS is entirely possible to do on residential mains circuits.


> I've not had that in a decade, and only for really shitty devices. I've also had crappy PoE devices stop working, ports blow.

Every ESP32-based WiFi device _will_ at some point get stuck in the disconnected state. It's almost an ironclad guarantee.

> UPS is entirely possible to do on residential mains circuits.

Sure, but then you're getting into the "whole house" backup with subpanel, transfer switches, etc. You can install backup for your router as a small UPS, but then I also have cameras, doorbells, sensors, etc.

If you already have a house without Ethernet wiring, then opening up the walls just to run PoE makes no sense. But if you're building a new house or if you have pre-existing wiring (and a lot of newish houses do), then PoE is a no-brainer.


> Every ESP32-based WiFi device _will_ at some point get stuck in the disconnected state. It's almost an ironclad guarantee.

See earlier note about crappy devices.

> Sure, but then you're getting into the "whole house" backup with subpanel, transfer switches, etc. You can install backup for your router as a small UPS, but then I also have cameras, doorbells, sensors, etc.

Well you can get small UPS for them too, but sure there are probably some points you can find around your corner of the envelope where PoE makes sense. That's not where many people are though.

> If you already have a house without Ethernet wiring, then opening up the walls just to run PoE makes no sense. But if you're building a new house or if you have pre-existing wiring (and a lot of newish houses do), then PoE is a no-brainer.

Not many new houses do at all because it costs money nobody really wants to pay. A builder will put some in if you ask but not off their own bat because they think it'll make the house worth more, because it won't. So unless some super nerd like your or I ask, no houses will be wired for ethernet. There was a brief window where wifi was non-existent or pretty slow and terrible where it got slightly popular, but that's long past.

If I was building a new house I would wire ethernet from a small server room/cupboard to just several places for wifi APs, plus ethernet and fiber from there to office. No PoE, they would all have USB-C power from same/adjacent wall plate as ethernet. And would probably look at solar+battery system with UPS capability, especially if I lived somewhere with shitty mains power. But even that is not appropriate for normies. They'd just buy a few mesh/repeater wifi things, not care that much about power going out once every few years, and be done with it.


It depends on what you want to do. CA certs are easy to manage, you just put the CA key instead of the SSH public key in authorized_keys.

They also provide a way to get hardware-backed security without messing with SSH agent forwarding and crappy USB security devices. You can use an HSM to issue a temporary certificate for your (possibly temporary) public key and use it as normal. The certificate can be valid for just 1 hour, enough to not worry about it leaking.


> With SSH certificates you have to go back to the "keys to the kingdom" antipattern and just hope for the best.

Whut? This is literally the opposite.

With CA certs you can create short-lived certificates, so you can easily grant access to a system for a short time.


And what about the CA?

It's no different compared to regular SSH private keys. You need to protect it from compromise.

However, it provides you an additional layer of protection, because it does not need to be on the critical path for every SSH connection. My CA is a Nitrokey HSM, for example. I issue myself temporary certs that are valid only for 6 hours for ephemeral private keys.


Yes it is different. SSH CA keys are harder to secure and attackers have a much bigger incentive to steal them.

You can also configure multiple CA for client auth, and on the client side multiple ca to verify host keys.

Hosting IMDS on the host side is pretty much the only reasonable way to provide stability guarantees. It should still work even if the network is having issues.

That being said, IMDS on AWS is a dead simple key-value storage. A competent developer should be able to write it in a memory-safe language in a way that can't be easily exploited.


“No, there is another”—Yoda, The Empire Strikes Back :)

What you describe carries the risk that secrets end up in crash dumps and be exfiltrated.

Imagine an attacker owns the host to some extent and can do that. The data is then on disk first, then stored somewhere else.

You probably need per-tenant/per-VM encryption in your cache, since you can never protect against someone with elevated privileges from crashing or dumping your process, memory-safe or not.

Then someone can try to DoS you, etc.

Finally it’s not good practice to mix tenant’s secrets in hostile multi-tenancy environments, so you probably need a cache per VM in separate processes…

IMHO, an alternative is to keep the VM's private data inside the VMs, not on the host.

Then the real wtf is the unsecured HTTP endpoint, an open invitation for “explorations” of the host (or the SoC when they get there) on Azure.

eBPF+signing agent helps legitimate requests but does nothing against attacks on the server itself; say, you send broken requests hoping to hit a bug. It does not matter if they are signed or not.

This is a path to own the host, an unnecessary risk with too many moving parts.

Many VM escapes abuse a device driver, and I trust the kernel guys who write them a lot more than the people who write hostable web servers running inproc on the host.

Removing these was a subject of intense discussions (and pushbacks from the owning teams) but without leaking any secret I can tell you that a lot of people didn’t like the idea of a customer-facing web server on the nodes.


Of course, putting the metadata service into its own separate system is better. That's how Amazon does it with the modern AWS. A separate Nitro card handles all the networking and management.

But if you're within the classic hypervisor model, then it doesn't really matter that much. The attack surface of a simple plain HTTP key-value storage is negligible compared to all other privileged code that needs to run on the host.

Sure, each tenant needs to have its own instance of the metadata service, and it should be bound to listen on the tenant-specific interface. AWS also used to set the max TTL on these interface to 1, so the packets would be dropped by routers.


> Why don't you want every device to have a public IP?

Suddenly, your smart lightbulb is accessible by everyone. Not a great idea.

> With IPv6, if you want a peer-to-peer connection between firewalled peers, you do a quick UDP hole punch and you're done - since everything has a unique IP, you don't even need to worry about remapping port numbers.

There is no guarantee with IPv6 that hole punching works. It _usually_ does like with IPv4.


> Suddenly, your smart lightbulb is accessible by everyone. Not a great idea.

The answer here is kinda that Wi-Fi isn't an appropriate networking protocol for lightbulbs (or most other devices that aren't high-bandwidth) in the first place.

Smart devices that aren't high bandwidth (i.e. basically anything other than cameras) and that don't need to be internet accessible outside of a smart home controller should be using one of Z-Wave/Zigbee/Thread/LoRaWAN depending on requirements, but basically never Wi-Fi.


Silliness of smart bulbs aside, I would hope the answer is how ipv6 is actually safe for this, not that you should just not use wifi.

Well Thread uses ipv6 in a safe way for this, nobody ever complains about how they wish their Thread network only used ipv4. :)

>> Why don't you want every device to have a public IP?

> Suddenly, your smart lightbulb is accessible by everyone. Not a great idea.

Why would it be "accessible by everyone"? My last ISP had IPv6 and my Asus (with the vendor firmware) didn't allow it. My printer automatically picked up an IPV6 address via SLACC and it was not "accessible by everyone" (I tried connecting to it externally).


> Suddenly, your smart lightbulb is accessible by everyone.

A firewall solves that issue, IPv4 or IPv6.


A lot of people, even on HN, mistake "addressable" for "accessible".

It's because router defaults have been bad for a long time and NAT accidentally made them better.

I finally have IPv6 at home but I am being very cautious about enabling it because I don't really know what the implications are, and I do not trust the defaults.


To be fair, if I had $999 million, it'd be bugging me all the time until I got to $1B.

> To be fair, if I had $999 million, it'd be bugging me all the time until I got to $1B.

Conversely, it'd be bugging me until I got to $50M because even in my wildest fantasies, I'd find it hard to spend even $50M in the years I have left.

(Obvs. the calculus would be different for someone in their 20s / with kids.)


Yeah, but you have to be really careful or you’ll pull the handle just a bit too much and hit $1,000,000,000.01.

It's fine, it's a nice palindromic number!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: