shockinglytrue

Please review the HN community guidelines before posting something like this in future

I prefer Newspeak

With thanks in part to the security community and part to Intel, the budget that can be spent avoiding a syscall just keeps increasing every year

This read more like an advert than a comment, and that is certainly the most loaded question I've ever seen in written English.

Giant centralized troves of personal data are a huge risk to everyone. Civilization pivots and mutates rapidly, and it's clear to nobody at any particular time which way it may lean next, or whether it will lean toward them or on top of them. If anyone had told you there'd be global mass beheadings of century-old statues 3 weeks ago, I suppose you'd have been laughing then too.

Unsurprisingly for a spec from Fastly & CloudFlare, the privacy offered is predicated on the existence of large centralized providers that due to their size cannot be blocked. One outcome of this design is that if you want to offer truly private service to an end user, you must have a relationship with one of these providers, otherwise your traffic, even if it implements the spec, becomes easily identifiable as its EKR config was served by some unique non-shared infrastructure.

In practical terms I guess it is reasonable, but viewed from the angle of how the Internet was originally intended to work, it is obviously abhorrent and self-serving.

Centralizing the log files for the majority of Internet services in the hands of a few companies will never be good for security

Far from it. It's quite likely going to be over 5 years if not a decade before it would be possible to run a pure-HTTP3 service without risking connectivity problems

The problem is similar to the IPv6 transition, except thanks to the browser monopolies, it's possible at least for network providers to quickly feel significant pressure to fix their networks. But there will always be some networks that will never be fixed

edit: for those inexplicably downvoting this, please pay attention to the parent comment's question, and the Internet's long chequered history of adopting new protocols in any setting. TCP port 443 isn't going to magically disappear overnight, or indeed any time soon. This is evidently true because it has been true for all prior transitions. Mail still flows to many places unencrypted despite the standardization of STARTTLS 21 years ago. The long tail has only gotten much longer in those intervening 21 years.

Now all those traffic shaping middle-boxes are worthless

No reasonable implementation of encrypted SNI has been proposed or standardized. Those middleboxes are still more than useful

AFAIK in QUIC there is some light obfuscation of the ClientHello, but it is not intended to be an anti-filtering measure, middleboxes can still fish out any presented name with a little bit of new code

But doesn't that criteria also describe every open source mailing list ever?

Wish all distros shipped https://github.com/vozlt/nginx-module-vts by default. It's a minor pain to self-build

It always strikes me as uncannily brave to see a post like this. So many statements associated with one username..

- I no longer work at $company, and their stuff sucks

- ergo, they fired me, or I left on bad terms

- I clearly didn't get on well with my coworkers, as I'm happy to shit on their work from across the pond

- ergo, I have some deep attitude problem I'm likely to bring to my next placement

Stream is for VOD, live TV is an entirely different problem

The EU could build support for this 1000 different ways. They need only shake another GDPR-shaped stick that gently encourages business to buy local and the rest would be history. But they can't really do that yet, because there is no viable local market.

Look at Huawei to see how effective government bureaucracies can be when they decide to compete with efficient business.

This isn't the first route leading straight to satellites. I forget the name of the provider, but there is at least one big allocation where whatever you're sending to it is basically coming straight back down as radio.

Pretty hilarious, 32gb sodimms are only 150 GBP in the UK, Apple charging 200 for 16. Similarly, 2TB disk for 800 GBP, open market it's 219.

Some PC laptop vendor could do a whole TV campaign based around the idea of turtle-necked folk setting fire to money and smiling, because it makes them feel better, and that's really all that matters[.. right?]

Basically most of what runs on k8s, including most of the k8s control plane, lives in a container. So for the most part, the only material concern about the host machine and OS is what kernel it is running, because that may limit what kind of jobs you can run in the containers.

I don't understand all this angst. In a well run infrastructure, Kubernetes basically just boils down to a new config file to describe some proxy rewrite rules, and how much RAM your thing needs.

If you want to run VPS-sized pods full of untracked mutable state with their own ghetto logging / monitoring / deployment / configuration management baked in, nothing is stopping you, but by the time we're "maintaining production systems", and we discover that crumby little $5 VPS has been touched by 7 people over 2 years, nobody knows what is on it any more, turns out the default logrotate configuration was shredding audit logs, and nobody has a clue how to reinstall it without literally starting over, things start to look a little different.

- "I wish I had a list of all the jobs that were supposed to be on this VPS"

- "I wish I didn't have to setup random log archiving cronjobs for all these apps"

- "I wish I knew what directories I need to back up"

- "I wish I could split this one job off the VPS without having to rewrite and retest its config"

- "I wish I could run a separate deployment environment on the VPS without having to set up a whole new VPS"

- "I wish I could rotate this API key but I haven't a clue where it is stored or what is referencing it"

- "I wish I could give the intern access to deploy the web site without letting him also take a copy of the HR database"

- "I wish I could deploy this new job version and roll it back if I fuck things up"

- "I wish I could run this ancient proprietary tool that needs 32bit libs from Debian 0.4 without installing them globally and potentially bricking the whole VPS"

- "I wish I didn't have to go install and configure a bunch of monitoring plugins every time I deploy a new app"

You can set all that up by hand of course, after all it does represent years of fruitful low-intellect busywork for idle hands, or you can come up with your own self-assembled collection of third party tools to do it for you, investing the research, installation and configuration time that entails, and accepting the cost of having created an ad-hoc system only you understand, or you could simply pick one big framework that does it all at once and try to make it work.

The nice thing with the one-big-framework approach is that you also get a common language and operational model understood by thousands of people you can hire on the open market. They understand how your configs are laid out, they know how to discover mutable state and query the health of all your existing jobs. And by the time they leave the company, you can understand all that about the work they've done.

This is only addressing Kubernetes as an operational methodology. Containerization as an architectural style is an entirely different topic.

Managed to miss this, thanks. I'd be interested to hunt out the BPO ticket at some stage to see if they benchmarked on NFS or spinning rust

The Django development server's asynchronous auto reloader is neither unique nor uncommon.

Managing self-installed k8s is a pain in the ass right now, but not much more than trying to manually install Linux without using e.g. the Ubuntu installer. Would that put you off using Linux?

Speaking as a daily Linux user since 1996, there are so many parts of the system I still don't understand, but it's not necessary for me to e.g. understand exactly how the font catalog and text rendering works to write a document. The same is true here.

There are quite a few companies in this space trying to improve the self-hosted experience, just give it some time

As for all the tools you supposedly need, the only one you actually need is kubectl, and it's more than enough to accomplish everything. New ecosystems always endure this abundance of "helpful tools" before consolidating on a few important choices.

Difficulty with git basics is the least of your worries. For example pycs are fundamentally racy, it is quite possible to have a .py newer than a .pyc depending on how unlucky you were with an in-progress deployment, or some tool that never updated the .py timestamp. Python continues to execute the pyc even though the code changed, since the minimal benefit of the pyc would be rendered significantly inert should Python use any kind of strong check (instead of just comparing second-granularity stat() output) to ensure the cached bytecode matches the source. In this way, without your permission, Python silently plays undesirable code execution roulette with your computer every time it starts, for as long as you have the feature enabled.

I have lost count of the number of times I've seen someone lose an hour due to it. I can also count many instances of QA environments becoming inexplicably bricked by it. The correct fix for this requires opening the .py and hashing its content, at least doubling the amount of IO required to start a program. They were a great feature when parsing small files was noticeably slow, but this hasn't been true for almost 20 years.

It's therefore worth turning the question around: why do you think pyc files are useful?

Highly recommend "export PYTHONDONTWRITEBYTECODE=1" in your bashrc and just forget about it. Pyc files are still an important optimization on modern machines in some circumstances (especially with huge oft-restarted apps), but the autogeneration behaviour has always been a pain in the ass

The bulk of your pycs are generated during package install. What tends to remain in the usual case is a handful of files representing app code or similar.

What kind of laptop bag do you use for the monitor?

Typical ill-considered comment from Linus, and surprising for someone getting on his years. Column width is an accessibility issue.

I'm barely in my mid 30s and the average font size has been steadily creeping, maybe 1.5 pts per 5 years.

I could tolerate 132 column files today, but by the time I'm 50 there is no way this will work, regardless of screen size

Thanks for this. I'm absolutely in shock this process is so industrialized, and that it has apparently managed to survive so long, and even through fake news being a huge topic in US politics

I wasn't aware press releases could include a script for a presenter. Is this really common? What is the industry name for these packages?

There are authors.. https://www.google.co.uk/search?q=site:reclaimthenet.org+inu...

But none of them seem to have LinkedIn profiles, they're quite possibly pen names.

The contact page lists a UK country code Signal number, so they're probably based there.

Some of the names appear on other sites with the same nav structure.

It is definitely a signal, but not an automatic indicator of something nefarious. There could be a whole host of good reasons why they're doing that. For example, the site could be launched as an experiment by a non-profit whose core work should not be associated with a risky message (this is my current favourite idea), or might piss off their funders.

FWIW there is a ton of newswriting on the Internet occurring under pen names for one reason or other. A lot of writers in the middle east will not or cannot use their real names.

I have never witnessed a company at least the size of Uber where this wasn't the case. This isn't exclusively a culture thing, it's a bandwidth thing. There is limited human IO available to coordinate, and available bandwidth diminishes in proportion to org size. The org can either choose to slow down to match available IO, or run at closer to natural pace and accept duplicate work. I guess the latter must be the obvious choice, or the automatic tendency

I imagine the same problem is why so many large orgs inevitably turn into hyperstructures of insane management layer cake.. coordination overhead will eventually send everyone begging for the ability to shed work or delegate

Not sure why you're being downvoted, this unfortunately all makes sense

It's still possible, you just have to dance around a little more

In one project we work around this by shipping a tiny wrapper in the APK to exec that then uses dlopen() on the target, which is now built as a library.

Pretty sure a generic hack could be made to run unmodified executables this way. Certainly in the security community userland ELF loaders are very old news, even X11R6 had its own at one point