Nope, they don't add. They confuse. From administrator perspective, it sucks when the same conceptual configuration can be performed in many different places using different configuration languages, governed by different upgrade policies, owned by unintended users, logged into unintended places.

Also, I'd bet my monthly salary on that Node.js implementation of this feature doesn't take into account multiple possible corner cases and configurations that are possible on the system level. In particular, I'd be concerned about DNS search path, which I think would be hard to get right in userspace application. Also, what happens with /etc/hosts?

From administrator perspective I don't want applications to add another (broken) level of manipulating of discovery protocol. It usually very time consuming and labor intensive task to figure out why two applications which are meant to connect aren't. If you keep randomly adding more variables to this problem, you are guaranteed to have a bad time.

If you're confused over such things, you're a crap admin.

Oh, so we are launching attacks on personality now? Well. To start with: you aren't an admin at all, and you don't even understand the work admins do. Why are you getting into an argument that is clearly above your abilities?

And, a side note: you also don't understand English all that well. "Confusion" is present in any situation that needs analysis. What's different is the degree to which it's present. Increasing confusion makes analysis more costly in terms of resources and potential for error. The "solution" offered by Node.js offers to increase confusion, but offers nothing in return. I.e. it creates waste. Or, put differently, is useless, and, by extension, harmful, because you cannot take resources and do nothing and still be neutral: if you waste resources while produce nothing of value, you limit resources to other actors who could potentially make a better use of them.

OK, I'll bite. Do you think Node.js implementation is aware of DNS search path? (My guess would be that it's unaware with 90% certainty).

If you don't know what DNS search path is, here's my informal explanation: your application may request to connect to foo.bar.com or to bar.com, and if your /etc/resolv.conf contains "search foo", then these two requests are the same request.

This is an important feature of corporate networks because it allows macro administrative actions, temporary failover solutions etc. But, if a program is configured with Node.js without understanding this feature, none of these operations will be possible.

From my perspective, as someone who has to perform ops / administrative tasks, I would hate it if someone used these Node.js features. They would get in the way and cause problems because they are toys, not a real thing. Application cannot deal with DNS in a non-toy way. It's the task for the system.

Oh I'd be very surprised if Node's implementation would handle such situations.

I also wouldn't really expect it to though, that depends heavily on the environment the app is run in, and if the deployment environment intentionally includes resolv.conf or similar I'd expect the developer(s) to either use a more elegant solution or configure Node to expect those resolutions.

Then you are sort of saying: I expect Node.js implementation to be bad... why do you need a bad solution if a good one is within hand's reach?

In other words: Node.js doesn't do anything better, but, actually does some things worse. No advantages, only disadvantages... then why use it?

Why would a desktop program need these sort of restrictions?

Because I don't trust the developer not to have security holes in their code.

But you are asking the developer to make these restrictions... Node.js is the user-space program, controlled by developers. Ops shouldn't (need to) deal with it.

This is what process' mount namespace is for. Various container implementations use it. With modern Linux you don't even need a third-party container manager, systemd-nspawn comes with the system and should be able to do that.

The problem with the "solutions" s.a. the one in Node.js is that Node.js doesn't get to decide how eg. domain names are resolved. So, it's easy to fool it to allow or to deny access to something the author didn't intend for it.

Historically, we (the computer users) decided that operating system is responsible for domain name resolution. It's possible that today it does that poorly, but, in principle we want the world to be such that OS takes care of DNS, not individual programs. From administrator perspective, it spares the administrator the need to learn the capabilities, the limitations and the syntax of every program that wants to do something like that.

It's actually very similar thing with logs. From administrator perspective, logs should always go to stderr. Programs that try to circumvent this rule and put them in separate files / send them into sockets etc. are a real sore spot of any administrator who'd spent some times doing his/her job.

Same thing with namespacing. Just let Linux do its job. No need for this duplication in individual programs / runtimes.

The part you're overlooking is how easy a vulnerability within the application can escape & do damage. Such vulnerabilities could either be someone hacking the application or a supply chain vulnerability. Namespacing & similar techniques limit the blast radius of a compromised process on the rest of the OS, but do nothing to limit the blast radius of a compromise on the assets accessible by the process. For example, if I have a document editor and want to open documents on my OS, namespacing doesn't help - the document editor traditionally needs the ability to open and list files.

Comprehensive capability protection is needed so that you actually need to have a token to do something privileged even within the process. What that looks like is the OS shows a file dialog and gives the process a descriptor (with a random ID) to that file. Similarly, network I/O would need a privileged descriptor the OS gives the application. Then even if you compromise the process you have to fully compromise the process to find the token to do privileged actions with.

I was born in Ukraine and moved to Israel (made "aliyah") in 1999. I moved to the Netherlands for work in 2021.

I'm not an Israeli by Israeli standards :) And will never be. But, of course, I'm a citizen, I can read and speak Hebrew well.

Politically, you can say, I came full circle. As many newcomers I was fed a very simplified and one-sided story of Israeli-Arab relationship. The first time I ever cast my vote in elections I voted Shinuj (they are farther right than Likud). In general, immigrants from the former Soviet Union tend to vote right and be pro-settlers.

For non-political reasons I ended up in military jail, where I met some "prisoners of consciousness" who, while didn't convince me to switch my political position entirely, exposed me to the leftist ideas delivered by the leftists. It's very important to see such ideas through the eyes of supporters because the other side virtually always misrepresents them to score points.

I didn't care about elections for a while, but, eventually, when I finally decided to vote, I voted Meretz.

I don't think I will vote in the next elections. Or, maybe, out of habit, I'll vote Democrats (former Labor and Meretz together)... but, really, I don't see a good candidate.

Anyways, what made me depart from the liberal camp is the European liberals. Pathologically bad decisions, or, even more often, the complete lack of any decisions. Gullible and zealous about issues they don't understand... I just don't want to associate myself with people like that. And I see how Israeli liberals parrot the European liberal's believing they know better.

* * *

So... to try to give some sort of a breakdown on who in Israel stands with settlers and why:

* Working class hates Arabs. It's plain and simple: working class often has to work in mixed environments. Construction, hospitality, agriculture. And there Arabs are just danger. You have to look over your shoulder all the time to make sure Mahmud isn't in a bad mood today and didn't bring a knife to work, and isn't going to cut you. I worked in a chain restaurant where a line cook brought a bomb one day to work and killed a bunch of people, himself included. Any Israeli who worked blue collar jobs probably has a story like that. These people don't care about the technicalities or long-term consequences of illegal settlements. Whoever harms Arabs, they are voting for that guy.

* Healthcare holds a special place in white collar jobs because there are a lot of Arabs working in it. But these are not the brutes who come to work with knives and bombs. Also, doctors Jewish doctors are exposed to Arab patients and the other way around... this creates a more friendly atmosphere. You will also find that doctors in Israel are probably the most leftist of any occupation.

* White collar jobs in general want to see Israel copying Europe. People in these jobs tend to want the rule of law, equality, secularism, inclusivity. They see settlers as either crazy or brutish and don't want to associate with them. Even if they may hold right-wing views, they want the implementation to be lawful and non-violent if possible.

* Black-kipah orthodox Jews only care about themselves. For better or for worse. They only wake up when politicians directly address their interests. If settlers go berserk on Arabs or Arabs eviscerate the settlers: they don't care.

* Knitted-kipah orthodox Jews are the settlers (not all of them, but probably a majority). They believe Israel should be restored in some sort of historical borders... as per usual, those borders aren't very certain, but they would quite certainly encompass a place called Judea and a city called Jerusalem. They believe they are doing a favor to the Jewish community by fighting "invaders" (Arabs).

* Israeli Arabs... are a mixed bag. You can find literal jihadists and those who hate other Arabs on the other side of the fence more than settlers do. It's very clanish and way too involved to try to parse it.

* The owners class, the rich people, they despise settlers. See them as an inconvenience / a bunch of lunatics. They don't care about Arabs either.

* Immigrants, especially fresh, tend to overwhelmingly support settlers because they misunderstand their status and genuinely believe the settlers are doing what the country isn't allowed to do due to some political scheming going on.

The company I work for is guilty of abusing 3. We use it for debug output of user-supplied scripts that are meant to implement monitoring / metrics :'(

This is the first time I hear about stddata though. Is this a thing that's going into a standard? Is there already? Or is it just a name someone gave to it and it's not a real thing?

Not enough programmers talk to QA, and so are oblivious to testing.

The benchmarking here is... pointless. Here's my story (of writing a Protobuf parser) to illustrate why. I already wrote about it before, but it keeps happening, so, maybe repeating it is not such a bad thing.

So... the official (coming from Google) Protobuf parser for Python is ridiculously bad. It generates Python code for the parser. Not only is this unnecessary, it's also executed poorly. So, I decided to roll my own. Also, I decided to make it multi-threaded (I wrote it in C, with Python bindings).

Then I tried to benchmark it against the official implementation. I don't trust the quality of Python language implementation, so, that came under the spotlight first. For example, I chose Python's enumerators to represent Protobuf enumerators. Turned out that was a horrible decision because instantiation of Python's enumerators is extremely resource-intensive. I had to make a few similar adjustments, searching for the less resource-hungry Python built-in data-structures.

And yet I was still far behind on my benchmarks. So, I tried to understand what the Google's C++ code was doing. And then I realized that Google's parser in the "first pass" only extracted the top-level messages, not even trying to parse the hierarchical structure. This structure was only extracted on-demand. So, essentially, I was competing against memcpy()...

But, here's another catch: most real-world applications will not want the "intermediate" Protobuf structure made up of general-purpose data-structures such as dictionaries or enumerators. They will want them immediately parsed into domain-specific data-structures. So, a parser that offers this kind of functionality might be slower to parse into generic data-structures, but will win in real-world benchmarks.

Of course, the percentage of useful payload is also important. Typically, applications underutilize the messages they exchange. But, to what degree is different and completely dependent on application design. Similarly, mapping into domain-specific objects will depend on the sort of information the application wants to exchange. Protobuf is bad for column / tabular data, but somewhat better for object graph kind of data. Protobuf is bad for large messages with duplicated content, but is somewhat better for short messages with little duplication.

All of this, and much more, allows for a lot of variability in benchmark design, and would allow me, or anyone writing a parser to skew the numbers in whatever direction I want... to amuse the general public.

Neither of them are well-designed or well thought-through. They address some cosmetic issues of Protobuf, but don't really deal with the major issues. So, you could say they are slightly better, but the original was bad enough to completely disqualify it either.

Flatbuffers lets you directly mmap from disk, that trick alone makes it really good for use cases that can take advantage of it(fast access of read-only data). If you're clever enough to tune the ordering of fields you can give it good cache locality and really make it fly.

We used to store animation data in mmaped flatbuffers at a previous gig and it worked really well. Kernel would happily prefetch on access and page out under pressure, we could have 10s of MBs of animation data and only pay a couple hundred kb based on access patterns.

We run an airgapped version of JIRA (but we are a very big company, globally distributed). Performance is in the gutter.

The annoying part is the amount of garbage fixes in JIRA's UI. For example, because of the loading speed, and me losing patience with it, if I don't wait for the page to finally finish loading and click on the "create" button, then instead of the modal dialog for issue creation, I get a whole new page for issue creation. Both options are atrocious from UX perspective (because usually I need to copy text from the issue I was reading into the issue I'm creating), but at least when it's a modal window, I can pop open the developer tools and delete the modal part that prevents me from copying the text from the issue otherwise blocked from interaction.

Also, it looks like due to speed, some queries simply don't finish on time, and randomly, searches don't find all the issues they should. Especially searches that ask for "s.t. parent issue has such-and-such properties".

Ultimately, JIRA isn't built to scale (ironically, since it's written in Java, which was always defended as being slow for small problems but scaled well). The code has a lot of assumptions about some operations being fast enough to not require buffering / incremental implementation. And sometimes you hit the combos of such unoptimized operations and have to wait minutes for the program to respond.

The answer is YES, and this type of shifter is a favorite among mountain bikers whose reliability needs and "field conditions" are already much more challenging than your average biker.

There are plenty of examples of situations where a wireless setup simplifies things.

I used to put wired speed/cadence sensors on my bike. Now I just zip tied two BLE gyros to the wheel and crank and things are vastly simpler. I've had them there for years and still haven't changed the battery. I've also never tangled the cables or had to fiddle with the mounts for a magnetic sensor.

It simplifies installation and getting a reliable, comfortable shifting setup, yes. Installation is simplified, especially in the case of internal and headset routing, which is something the target audience would deal with in case of cable-actuated derailleurs. Changes requiring adjustments over time due to the cable wearing out or stretching are eliminated, simplifying maintenance, both during and in between rides. On drivetrains with front and rear derailleurs, it has an optional adjustable algorithm that shifts both together for you and chooses the best gear combinations as you press up and down, simplifying operations. Auto-shifting is available on some models. There's more possibilities to put the shift buttons in the most ergonomic place, or even put them in more than one place, simplifying setting up your bike for comfort. That it doesn't simplify fixing your derailleur in the middle of a ride doesn't negate all of its benefits. Yes, the radio or battery could fail, but on the other hand it is less prone to go out of adjustment.

Also it has one killer feature and everyone that tries one also raves about how well it works. You know those little ramps stamped into the side of the sprockets on a cassette, that the chain moves up and down on as you change gears? Di2 delays your shift precisely until the start of a ramp, which makes shifting faster and works much better under load. That crunch and possible stuck chain when you shift to start a climb is basically eliminated.

Is it something a bikepacker will choose? Probably not. Is is something attractive to many other types of cyclists and simpler to install, use and maintain in ways they care about? Yes. I'm a weekend mountain bike rider, not at all competitive. I personally won't get one because of the cost but the features are quite attractive to me, while the risk and consequence of a dead battery seem low. There are many, many other things that are more likely to break during a ride, many of which will have you walking back. A dead Di2 battery means you are stuck in one gear, and if your chain has a master link or you carry a chain tool (target demographic definitely has one or both) you can change the gear in 2 minutes.

I thought of an analogy for HN. Think about water cooling in a gaming PC instead using the stock CPU cooler. It's more expensive, but generally higher performing and quieter and arguably looks cool. There's a certain demographic who thinks they are stupid because they must have extra parts so which are difficult to install and must be less reliable, and they may have one horrible failure mode of leaking liquid inside your PC. They might give the example of a mission critical server, and be right for this use case that it's not a good idea, at least at the scale of one machine. There's another demographic who don't think twice about buying them because the positives easily outweigh the negatives for them. This group can sometimes be seen telling the other group that they are out of date on it being difficult to install (you can even buy a case with it pre-installed) and reliability (modern all-in-ones almost never leak). They will most likely concede that for a mission critical server it's not the correct product.