vetrom

X via ssh is still useful, and I will be unhappy with wayland implementations until desktop shells get usefully separated from compositors. They need to be able to die/crash/be restarted separately.

Rather older. This sort of thing started rolling out when Landscape came out, c.a. 12 years ago. Does Red Hat have something similar in RHEL?

The ROCm compilers are slightly different, the newest GCN arch is probably not well tested for compute yet. The ROCm stack's development and testing effort strongly focuses on their 'pro/server' line cards. Is there a Navi WX or the equivalent yet?

Not always. Cache speculation bugs for example I dont think are covered by emulations. (At least not explicitly. If the mmu model is the same and transparent enough I suppose those could 'pass through' but only if they're implemented on the same plat form.

This very much reminds me of https://en.wikipedia.org/wiki/The_Last_Ringbearer which will shamefully probably never see an English print release. It's an interesting work of research and writing.

I use this behavior in production systems where I have 'well-known' RFC1918 addresses I use for service bootstrapping/configuration. In the network engineering world, extra loopback interfaces are also used for similar reasons.

Two Ideas:

1. Does encouraging ORCHID addresses reduce the impact of enumeration attacks? 2. Linux at least has controllable behavior for cross-interface IP reachability, in arp_filter/arp_announce/arp_ignore per interface sysctls, and ip address scope, as exposed by iproute / netlink. Perhaps its more proper for VPN addresses to be a scope 'link' address, instead of a scope 'host' address. Maybe a 'vpn' scope of some sort could be defined in future kernels, but I'm uncertain what that would do that a scope link address does not?

2cents per GB vs 9cents per GB.

I've worked at at least one company where we found using Direct Connect to a data center somewhere and egressing via that data center instead of amazon saved us significant bandwidth costs.

If the article had more journalism and less interview-bites from conference workers and maybe more then a generic overview, I'd agree with you.

As it is, IMO this article seems like more filler, than anything else.

Zookeeper has implemented dynamic reconfiguration since circa 2013-2015ish, but it required support for the feature in clients, as well as servers. That said, implementing an autoscaler that manages that as well was not trivial, in my experience.

You make a good point. The design is costly and bad, I hope I wasn't arguing to retain it for historical reasons or anything like that. I do believe that the history of how PGP got there, and how its ecosystem became the sort of hydra that it is should be kept in mind for anyone trying to build a replacement.

The commercial factors that drove the engineering there I think is a real risk for any cryptosystem implementor, especially if they are trying to build or retain a userbase.

Signal does a great job of supporting activists. That's basically its intentional product focus. Everything an open source proponent engineer might want to promote is secondary. The focus on activism and trying to deal with large actors definitely looks like #1. Everything else about their product is secondary to that.

Signal's product focus has been at best un-encouraging to those who want to use it for anything else. Federation, I'm looking at you, but you've also got to take it in the sense that every single vendor that embraced the only realistic messaging federation standard of the 21st century went on to embrace and extinguish it in less than a decade.

This speaks to a few problems: 1. Messaging is hard 2. Security is hard 3. Logic about security is hard to reason. 4. Historically, anyone paid enough to care about this space hasn't had any sort of public interest at heart.

Any application that combines any of the three falls squarely into what the people at Latacora and the like would call a high risk application. I might disagree with much of their analysis, but in the lens of risk control, they are perfectly correct.

If you're trying to figure out how we got here, you've also got to realize that there was an avalanche of government and commercial entities whose goals are not in alignment with say, those who think the optimal solution is a home rolled provable trustless security system.

For myself and many engineers I'd bet, I'd say that's where we thought things should go in the 90s and early aughts. Some things are better now, but most are much worse.

Society and encryption's implications I would say have caught up with each other, and theres definitely something found wanting. There's definitely say a market opportunity there, but there's also another big challenge that I read reviewing a discussion about package signing lately: "Nobody in this space gets paid enough to care."

That's what separates people like Signal, even if some of the engineering crowd doesn't like the way they delivered.

This is a bit of a ramble, so there's two afterwords:

1. Much of the morass about PGP is explicitly due to the environment, space, and time in which it was developed. This does not boil down merely to 'it wasn't known how to do it better.' There were decisions and compromises made. I think the writer at Latacora is not giving the history of the piece justice. That's OK though, because that's not the crux of their argument. It would be good though I think if they gave that a further explanation than why things like the byzantine packet format are impossible to explain, even if that explanation were only a footnote and reference. (Writing the history of how it got there is absolutely doable, but it would make for a dryly humorous history, at best.)

2: The open source and (linux/others?) distro community has tried hard, more than once to make this work. The development, design, and implementation burden though, is gargantuan. The overarching goal was basically to be compatible with every commercial system and maybe do one or two things better. What the article casts as purely a liability was the only way to get practical encryption over the internet well into the early '00s.'

Regardless of all that though, PGP is still a technical nightmare. If you dismiss it though, even when we have better components, I worry that we'd only repeat these mistakes. If you work in any sort of crypto/encryption dependent enterprise, please find and study the history. Don't just take the (well considered) indictment of PGP at face value. There's important lessons to be learned there.

Thats because most of the ElasticSearch data model is materialized indexes. You need to reindex (or use one of the other ops which amounts to building a composite index) to create different aggregates. Otherwise you need to use constructed JSON queries instead of adhoc lucene string searches to build the more complicated searches on those fields. Kibana provides tools that can help visualize building those if you don't do it from scratch, but its definitely a different workflow than Splunk or something implementing a more traditional query language.

On a modern OS (like anything in the last 25-odd years that has demand paging) that code isn't even loaded into RAM before it's used in many situations.

While that is an additional load if you deal with those formats, the root of things like startup and runtime bloat lie elsewhere.

With an amazing team, I'm helping run a fleet of a few hundredish pi3/3b+ and hundreds of pizero-W cameras in an evolving automotive IoT solution.

It's definitely been a challenge using them in volume, but they've been surprisingly reliable once you control for things like heat dissipation and get a decent networking solution. (At our scale we're approaching having to decide if we want to be a MVNO.)

Is it just me or is this being offered at a 1000% markup or so?

Credit score bureaus. A surprising array of services and accessibility is tied to the credit score.

The kexec paradigm makes this execution vector rather more useful than most people realize. It's also what powers inline kernel crash dumps.

haproxy is amazingly functional and has done a fine job of evolving over the years. At a particular $DEFUNCTCLOUDVENDOR we implemented a haproxy based ELB-ish solution with home grown control logic to replace a F5 installation whos configuration size grew unwieldy (the F5 config parser was falling over in their LBs) while we were nowhere near the F5's touted connection/throughput numbers. F5 wasn't really willing to work with us on licensing, so we implemented a system based on haproxy VMs that worked because we were more than a bit overprovisioned on switching capacity and were able to shard that configuration base more effectively over more VMs.

This was 2011, so I'd hope newer F5 gear has gotten past that.

SE tax is the employer share, and its a bit complicated. As a 1099, you are required to pay the full SE tax generally minus (a couple?) deductions. But then, you are allowed to deduct half of what you pay in SE tax from your income for regular income tax. The SE tax is also paid I believe only up to some income limit. Then, there's the Medicare tax on top of that, which is not income-limited.

besides, many of those applications depin when you install custom CAs, don't they?

I would presume he still holds a controlling amount of the company shares, and thus the board. He would likely be able to dis-appoint the (cloud?) of co-CEOs at his pleasure.

HSAIL depends on an ecosystem of non-free software components. Granted, it's an uphill battle to get the concert of moving pieces that would be needed for 3d/compute acceleration cards to work on a fully open source stack.

That said, getting GCC to do a better job implementing code for those is a big step in that direction.

for those who arent aware of some of the differences, a factual defense -- i.e. you're only speaking provable truth -- is not a defense against a libel suit in say the UK.

While HN does not have a great appetite for jokes, this sort of anti-chucknorris list could go far. That said, I also think much is lost between the journalistic climate between common / civil law jurisdictions, especially as it pertains to libel law. Wikileaks, as an organisation, and independent of any particular motivational bias has a clear and present interest in maintaining and pursuing a list such as this. I'm pretty sure pretty much any journalistic or advocational/lobbyist organanisation in any jurisdiction with a libel clause has a clear and present interest in maintaining this sort of stance, even if as an American you think it shouldn't be necessary.

That doesn't mean I agree with it, but if you operate in a commonwealth country and do anything controversial, I'd say it's pretty much mandatory.

My gaming box is still Xenial while all my work machines are at least bionic. While btrfs and my personal system setup practices make it easy to test and also port setups from machine to machine, I'm not relishing the moment when I'll have to bite the bullet and upgrade.

You could always add tek4xxx overlay support.

The article does a poor job of explaining the threat model, but I think you hit on the exact problem here. OOB baseboard management should not have direct access to other OOB management nodes, lest you invite that as an attack vector.

Unfortunately I'm going to bet a notable amount of networks conflate say routing layer and OOB management traffic and don't segregate the two (where often routing protocols need to cross communicate but OOB baseboard management does not.)

They goofed their letsencrypt renew cron job.