throwaway892238

I dropped out of school in 9th grade. I make $200K a year. A friend of mine has a college degree and has been unemployed for a year.

There is no uniform standard of education in the US. Kids in the South are being taught that evolution is on par with intelligent design. Poor black kids in Baltimore have on average a 3rd grade reading level in high school, while rich kids a few counties away are taught when to use a backdoor roth ira. Don't even mention "no child left behind".

Maybe let's calm down a bit with the judgement.

They're not revealing anyone's names. Names are anonymous by default until you elect to share yours.

It's both funny and sad when people find out how the real world works and get all indignant. "How dare they do a thing they're legally allowed to do! Rabble rabble rabble!!!" Glassdoor is trying to make money off you, like every other free site on the internet, and they will do whatever the law allows them to. Welcome to planet Earth.

Meanwhile, all the commenters in here are overreacting as usual, clearly not having read any of the terms of the website, like the part where it says your name is not disclosed until you explicitly elect to share it. But hey let's not let facts stop us from freaking out.

Hickey's definition of simple is wrong. It's not the opposite of complex at all. They are not opposites, nor mutually exclusive.

  - Easy is when something does not require much effort.
  - Simple means the least complex it can be and still work.
  - Complex means there are lots of components.

  - Easy is a concept that distinguishes the amount of work needed to use a solution
  - Simple is a concept that distinguishes whether or not there is an excess number of interacting properties in a system
  - Complex is a concept describing the quality of having a number of interacting properties in a system

"Deep", in the context of software complexity, probably only makes sense in terms of describing the number of layers involved in a piece of technology. You could make something have many layers, and it could still be simple, or be complex, or easy.

The "simple" in S3 is a misnomer. S3 is not actually simple. It's deep.

Simple doesn't mean "not deep". It means having the fewest parts needed in order to accomplish your requirements.

If you require a distributed, centralized, replicated, high-availability, high-durability, high-bandwidth, low-latency, strongly-consistent, synchronous, scalable object store with HTTP REST API, you can't get much simpler than S3. Lots of features have been added to AWS S3 over the years, but the basic operation has remained the same.

The high vis is paramount. The helmet... well, I just don't know how much good it would do if you get clipped by an F-150 going 60mph

The scary part of this to me is biking on country roads, especially with 55mph speed limits that big pick-ups regularly blow past. I live in a rural town, and I would be terrified to bring a bike outside slower town roads.

That's just one logistical problem (of many). The real reason we don't have flying cars is because we don't want them bad enough. If we spent enough capital, we could solve all the logistical and technical challenges and have flying cars. But the cost and effort it would take is so significant that nobody has yet had a good enough reason to do it.

Planes are good enough for going a long distance fast, and cars/trucks/trains are good enough for going a long distance slow. We could make a flying car, but for what? For individual people to go a moderate-distance fast? To go a short distance really fast? Cars and planes are good enough for our needs today without the huge investment in development of a new tech.

This is exactly the same reason internal combustion engines have ruled the roads for 100 years. Electric cars were preferred over ICE 100 years ago, but gasoline enabled us to go further for cheaper, so we accepted all the downsides, and industry made it convenient. It's only because we're suddenly afraid of our climate killing us that we're switching back to electric.

Every American utility company I have ever looked into has numerous crimes and controversies associated with it. It's kind of weird.

I actually suspect it's due to them being publicly traded. They literally are not allowed to do things that would jeopardize the share price, so they will hurt themselves and people in order to make a minor profit increase YOY. You shouldn't need to be a capitalist enterprise (with the whole "infinite revenue growth" thing) if your purpose is just to make sure your customers - who won't ever really grow much, because, you know, only so many babies born etc - have power, water, etc. But as publicly traded companies, their first purpose is just to increase shareholder revenue. If you end up (accidentally) burning down a forest, poisoning some communities, or compromising a state election with a fake candidate, that may just be an unfortunate side effect in the service of increasing the stock price.

That whole concept is bizarre. It's like wanting to fly, so rather than buy a plane, you take a Caprice Classic and try to make it fly.

If CoreOS actually wanted to make distributed computing easier, they'd make patches for the Linux kernel (or make an entirely different kernel). See the many distributed OS kernels that were made over 20 years ago. But that's a lot of work. So instead they tried to go the cheap and easy route. But the cheap and easy route ends up being much shittier.

There's no commercial advantage to building a distributed OS, which is why no distributed OS is successful today. You would need a crazy person to work for 10 years on a pet project until it's feature-complete, and then all of a sudden everyone would want to use it. But until it's complete, nobody would use it, and nobody would spend time developing it. Even once it's created, if it's not popular, still nobody will use it (you can use Plan9 today, but nobody does).

https://en.wikipedia.org/wiki/Distributed_operating_system

Agreed. If Linux were a distributed OS, people would just be running a distro with systemd instead of K8s. (Of course, systemd is just another kubernetes, but without the emphasis on running distributed systems)

When people call Kubernetes a "great piece of technology", I find it the same as people saying the United States is the "greatest country in the world". Oh yeah? Great in what sense? Large? Absolutely. Powerful? Definitely. But then the adjectives sort of take a turn... Complicated? Expensive? Problematic? Threatening? A quagmire? You betcha.

If there were an alternative to Kubernetes that were just 10% less confusing, complicated, opaque, monolithic, clunky, etc, we would all be using it. But because Kubernetes exists, and everyone is using it, there's no point in trying to make an alternative. It would take years to reach feature parity, and until you do, you can't really switch away. It's like you're driving an 18-wheeler, and you think it kinda sucks, but you can't just buy and then drive a completely different 18 wheeler for only a couple of your deliveries.

You probably will end up using K8s at some point in the next 20 years. There's not really an alternative that makes sense. As much as it sucks, and as much as it makes some things both more complicated and harder, if you actually need everything it provides, it makes no sense to DIY, and there is no equivalent solution.

No mention of how United and Optum are a racket that harms people and needs to be broken up

https://www.healthcaredive.com/news/unitedhealth-antitrust-i...

https://www.healthcare-now.org/blog/united-we-scam/

Oh, HN. Always upvoting the dumbest contrarian thinkpieces. It's like accidental 4Chan without the humor.

Sad that it's not a WYSIWYG. The old Visual Basic will forever be the benchmark for how easy it is to make a GUI. If it's not that easy I don't wanna hear about it.

Wanted to unsubscribe but they require you to login to do that. Can't recover account due to some recovery information supposedly being wrong? So I just mark them as spam. A bit insufferable but nothing else to be done about it.

STIGs are just references for implementations. The actual security standards are CMMC, made up of various DFARs, and FedRAMP for the cloud. Like you say, it does take on average 6-12 months to certify a new vendor.

The big problem is it's all self-attestation. I've worked for one of these vendors, and it was a lot of jackass business people who didn't actually care if anything was secure, they just wanted to "pass" their certification as quickly as possible and cut as many corners as they could. Didn't want to spend money on a contractor who knew how to actually pass these certifications, so instead they'd just lean on the IT dude and demand he complete things he didn't know anything about on impossible timeframes, asking him to do things which they might be legally liable for, and basically trying to avoid doing any actual security work if at all possible. Lowers cost, gets their project going faster which helps them land more contracts and get a promotion.

It's a strange thing to watch someone admit their own ignorance, and then immediately disregard it, in order to make a case for something that they - by their own admission - can't possibly understand. It's a doublethink poem. I don't think; therefore, I am.

Perhaps the disconnect is his belief that "what I do know is technology and UI/UX." Perhaps he really believes he knows how to build technology like this. But his complaints are those of a person who clearly only thinks of technology, as technology. Not as the stupid redneck in Arkansas who needs to use a shitty mobile connection in order to find out if diapers are on sale yet; but as the lofty technologist, surveying the digital landscape from his 100-gigabit 16-cpu latest-generation pocket powerhouse, flicking through content faster than it can render, concluding that the technological marvel of dreary old-world tech to be wanting.

The poor fools! They don't understand what I, a technology UI/UX expert, want in a mobile app! How foolish that they have not implemented what their competition has. It can only be incompetence. Not to worry though. I, the technological wunderkind, will write a blog post. I will educate them on their shortcomings, and inform them of the correct path to profitability. It's my duty to help these poor sods realize the truth: that they are not yet advanced enough. But with my help, they'll get there.

yeah, that's true

You've got to love the bravado of rich men and how easily they can take other people's money and flush it down the drain

For what it's worth, this website is geared more towards software developers than writers. That's probably fine? But your market is going to be much smaller than if you focused on writers and regular people. It wouldn't take a lot to make this better for regular people, but you would need to get a non-software-developer to sit down and tell you all the stuff you should remove, and product copy to rewrite.

As someone who got very good at DDR at a young age, and is now older, it's clear that if you do any exercise which challenges your balance when you're young, your balance will be better when you're old. I haven't practiced slackline or DDR in decades and I don't really exercise now, but I can still walk across a log found during a hike like it's nothing. Strength may come and go, but balance is clearly some kind of long-term muscle memory.

It doesn't matter what technique you use if you use it poorly.

That's a lot of mays. One might imagine that before this stuff becomes the latest version of an internet standard, these theoretical qualifications might be proven out, to estimate its impact on the world at large. But it was useful to one massive corporation, so I guess that makes it good enough to supplant what came before for the whole web.

Lol, wait, HTTP2 and HTTP1.1 both trounce HTTP3? Talk about burying the lede. Wasn't performance the whole point behind HTTP3?

This chart shows that HTTP2 is more than half as slow as HTTP1.1, and HTTP3 is half as slow as HTTP2. Jesus christ. If these get adopted across the whole web, the whole web's performance could get up to 75% slower . That's insane. There should be giant red flags on these protocols that say "warning: slows down the internet"

With their other losses they'll need some impressive financing to get anything new off the ground. Good luck securing that in 2024. Even if they get it, they're gonna take another bath if they try to target sub-$25K with a crossover. That's ICE territory; hybrids and all-electric crossovers are already $10-15K more.

Every developer needs to learn two lessons about great interfaces:

1. Layout, format [aka style], and interactivity, is both hard and necessary

2. Interfaces are subtly complex

Number 2 is the reason that "simple" formatting markup, like Markdown, will never be good enough to make a great interface. You can make a poor interface with Markdown, and that poor interface is good enough for very simple use cases. But people quickly get annoyed by simple use cases. They create friction, both for the designer and the user. More useful functionality is desired, and you need something more complex to enable that.

I've written a lot of tech docs. Markdown is one of the worst methods I've found to write them. Not because its formatting isn't intuitive, easy to remember, and easy to use. But because the documents it creates are not conducive to the purpose of the document: making it easy to read and remember information.

As for more general interfaces, the easiest way to understand why you need more elaborate methods, is HTML. When HTML was created by Tim-Berners Lee ~1990, he intended for format and layout to be independent and configurable. However, for years it lacked both formatting and layout options, and lots of people complained. It took six years for CSS to eventually become a standard, and before that, lots of hacks and incompatibility (and it turned out, more of them afterwards). The entire time people were complaining about how any document editor could easily format and layout exactly what the author wanted, but web browsers persisted in being difficult and inferior. Tables were only added in HTML 2.0, five years after the Web's birth.

You can still get by with not-very-good markdown, for not-very-good interfaces. But you will never have a Great interface without the ability to control layout, format, and interactivity, in subtly complex ways.

There is no easy way for a human to do that with text. But there is an invention that enabled users to create complex and rich layout, formatting, and interactivity: the WYSIWYG interface. With this tool, the human no longer needs to remember control characters, markup syntax, or formatting codes. The user no longer needs to spend endless time typing in code, displaying the result, being unsatisfied, and tweaking the code again, trying desperately to just get the screen to show them what they know they want. A WYSIWYG editor enables a human to completely discard any knowledge of how to format or layout content, and instead simply move things around on their screen with a mouse, completely eliminating complexity for the human, and enabling the creation of better content.

I think the reason modern software abandoned WYSIWYG, is that modern software isn't created for users. Most modern software is open-source (or close), and as such, it's created by developers, for developers. Developers don't want to spend time engineering a WYSIWYG, because they have no need for a good interface, and they don't care about wasting their time writing code. To them, writing code is the whole point, regardless of how long it takes, or what the outcome is. That's why Markdown was invented, and why people persist in trying to force Markdown to make something better, without realizing that that's impossible. They want to to build a castle, but they don't want to use anything other than the twigs and rocks lying about their feet.

This one weird trick will fix your memory leaks forever

The US, among other industrializing nations at the turn of the 19th century, had a pretty poor record for reliability, safety, etc. Over the years, local groups gathered together and lobbied for changes, usually to protect or defend a particular trade. Towards the late 19th century, more organizations were popping up to push for professional standards, licensing requirements, codes of ethics, public safety and social responsibility. For the better part of two centuries, this country (and others) have been very slowly yet incrementally improving how engineering is done.

Developing nations like India need their own time to move through similar processes. There still needs to be people lobbying, doing the work of organizing, and changing the way things work. But it's going to take decades, and maybe even centuries, like it did for other nations.

I think this paper is well-intentioned, but is trying to treat the symptoms rather than the cause.

The paper focuses on microservices, and then tries to avoid claims of "they just don't like microservices" by describing the ways in which microservices are improperly used. Do they go back and compare this to monoliths or other architectures? Nope; it's really just "hey I have another microservices idea", heavily gilded. They mention "monolithic applications divided into logically distinct components", but you could just claim your microservices are divided into logically distinct components.

They also seem to completely ignore the problem that a logical separation doesn't mean your components are better off. In a complex system, often completely separate components still need to be integrated together in order for the system to function at all, much less operate efficiently. It's not a design flaw to combine different things. It depends on the application. So just separating things logically isn't some scientific computing advancement, it's just categorization.

In reality, their solution (a "single binary business logic application" and "an interface that can combine them") is literally a description of shell scripting with Unix tools. Don't get me wrong, that obviously works great, since it's been popular for 44 years (older than IPv4). But if you want to come up with some kind of modern paradigm for distributed computing, maybe we should flush it out a bit more. What we have here is a Google engineer's attempt to make a paper suggesting we make shell scripting for the web, without much to show for it.

(Personally, I think the more people try to control the interface, the worse things get. The best and most long-lived solutions in all of computing have had almost no interface at all; a raw TCP stream, 3 raw file descriptors, a set of random arguments, and a set of random key=value pairs, have enabled all modern computing paradigms to flourish)