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

Don't most companies have a Git repo for skills that you can pull?

for developers working in claude code, sure. but there's ai users who don't use claude code. chatGPT business and enterprise tiers integrate with MCP servers controlled by your organization admin.

Because it costs money? Believe it or not, most places don't pay you 6 digit salaries for shuffling around YAML.

"6 digit salaries" is the second most common hacker trope after "having to justify". You don't need a six digit salary to purchase two laptops.

It is a fantastic init system/service supervisor. My problem with it is basically everything else. I think its developers see systemd as central to the entire system, basically the userspace counterpart to the kernel. I prefer the approach of 'dinit', but I understand why they designed it that way.

Due to this design they often have underspecified interaction between the different components, since the assumption is that everyone will use largely the same baseline systemd environment and as long as it works, who cares what it does underneath. If the different parts were more independent, they would be forced to develop a cleaner API contract between them.


I will add this: if you treat systemd as one trick pony and use for few use-cases which developers envisioned - it run flawlessly, but moment do something not in this path prepare for problems and inferior experience (example of randomly picked tool: timedatectl - no force update date like ntpdate command, you cannot quickly insert ethernet cable update date and disconnect... need to wait for synchronization)


SDL is a relatively high level API and framebuffer style graphics work fine on it. I think there are some edge cases for X11 with non-compositing window manager where you will get interesting glitches if the window moves.


Historically these weren't "edge cases"; all windowed environments sent a "redraw yourself" event to a window when it needed to be shown after having been covered up, that was handled specially by the application. In X11 this was an Expose event, in Windows this was called WM_PAINT. If you had a fancy X server back in the day, you could enable backing store; this kept a framebuffer of the window contents in memory even if the window itself was covered up that could be quickly restored upon exposure. This was incredibly useful and made redraws fast and glitch-free, but back in the days when RAM was expensive (you know, unlike today...) it could not be relied on in all X implementations. Compositing WMs have the equivalent of backing store for all windows, all the time.


Yes, only... 25m? You must have a bigger room than I do :)


Clearly it's the Big Room.


Hard links suffer from the general issue of there being two styles of writing to a file - open(2)/write(2) vs rename(2). Depending on the internals of each program you use to update the file, you will get very different results.

This is one of the ugliest parts of POSIX design, making idioms like -o /dev/null and file attributes unpredictable (I've had a server run out of disk space because a root-owned process used rename-style writing on /dev/null)


That was breakdown on a different level: your server process had no business of renaming stuff and it still did that. POSIX had nothing to do with this.


I'd agree if POSIX provided something like an open() flag which made the changes visible atomically, but as it stands, the rename() idiom is the mainstream way of durable file writing, so it is commonly used. Practical example using busybox sed: (GNU sed detects this case and refuses to overwrite)

  / # stat /dev/null
    File: /dev/null
    Size: 0          Blocks: 0          IO Block: 4096   character special file
    ...
  / # sed -i 's/foo/bar/' /dev/null
  / # stat /dev/null
    File: /dev/null
    Size: 0          Blocks: 0          IO Block: 4096   regular empty file
    ...


It's the fundamental idiom of how to do atomic file replacement. The sever process had better be doing that over editing a text file in a way that could leave it invalid if the process OOMs mid edit, or another process is reading it while it's being written.


If you use the VPN for the Web, browser fingerprinting is a major threat outside of specialized scenarios


In other words: a VPN service can't by itself solve all problems which potentially lead to deanonymization, it can only provide anonymous networking.

Why can't it aim to solve what it can do? TOR is a great example: the TOR network itself can't perfectly anonymize you due to browser fingerprinting, but users of the TOR Browser get both the TOR network resisting deanonymization on a network level and a browser with plenty of anti-fingerprinting measures built in. A VPN could aim to prevent deanonymization on a network level so that users who want to stay anonymous can use the VPN in combination with fingerprinting-resistant software.


Have you taken a look at Mullvad’s browser?


No, but it makes sense that they want to offer a complete privacy product and not just a VPN. The point is just that having a privacy preserving VPN is worthwhile, because one can use fingerprint resistent browsers, whether that browser is made by the same company or not. I imagine Mullvad + Librewolf would also make a decent package.


Mullvad have a Tor Browser fork for this reason.


If you blindly TOFU ssh sessions, those can be pwned easily in many common use cases. Legacy software configurations like NFS with IP authentication will be bypassed. Realistically the most likely scenario is using your home as a VPN, or a DDOS node.


yeah, and it's not like people recently launched a coffee shop that accepts payments over tofu ssh and a shell provider doing the same


It also sets a HN=1 cookie, so you may need to clear that or use incognito


I see. I'm using Firefox's containers feature and that prevented the cookie from carrying over.


AFAIK Lambda and everything else will use micro-VMs. No serious company would use a shared kernel design for workloads in different security contexts. (Personally I wouldn't even use the same hardware host, but sometimes sacrifices have to be made)


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

Search: