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

I don’t know man, Linux desktop in the 90s was extremely rough. It wasn’t until the 2000s with KDE 2 (though really 3 IMO) and GNOME 2 that Linux desktop started showing promise. It was then subsequently dragged down with many alternatives and infighting. Personally I think only KDE kept slowly progressing better. I didn’t even like KDE until GNOME 3 pushed me to it. Every now and then I try GNOME 3 to see where it’s at, and just get baffled by the choices they make. Both Windows and Mac also had baffling choices along the way (in terms of desktop UX). Windows more so obviously, but they both would course correct every now and then. GNOME seems laser focused on some desktop UX vision I can’t even begin to understand.

Not really sure what low end FOSS editors you are referring to? Textmate?. The Monaco editor predated vscode by 4 years and it was an attempt to build a browser-based texteditor as a take at cloud9 which people thought was gonna be the “future of cloud development”. Vscode happened after Atom (which was not low end) made electron apps viable and cloud9 turned out not to be the future. Both were an attempt at SublimeText (which was not FOSS). SublimeText itself was a cross platform alternative for textmate.

The FOSS text editor space was always crowded between vim and emacs. FOSS alternatives would get measured against these 2 behemoths and it was a tall order to compete against. Now FOSS IDEs were a different story.

Java, C#, and C++ had many sophisticated and advanced IDEs, some FOSS some not. However, PHP, Python, Ruby, and JavaScript were quickly gaining huge mindshare and those developers didn’t want to install Visual Studio, Eclipse, NetBeans, or IntelliJ. It’s a tough proposition to tell a Ruby dev to install Java, then install Eclipse, then install an extension, then learn Eclipse nonesense just to edit your Ruby files vs “just open SublimeText and edit your files”. Most of what those developers wanted was just syntax highlighting and basic directory navigation to begin with. Atom/vscode were an attempt at SublimeText alternative. VScode was objectively better than Atom and TypeScript was also objectively better than CoffeeScript.


To me it was about sublime getting a little too popular for web development. MSoft needed an answer and so vscode was born.

I agree. And that’s basically what I was alluding to.

The FOSS languages were taking over and there was less reliance on the traditional IDEs that MS (amongst others) were building.

MS wanted to appear more FOSS friendly so released VSCode.


Oh okay maybe I misunderstood because you said low end FOSS editors. When I think “low end editor” I think something like notepad or gedit.

Yes, fair point. I also meant FOSS languages and how they didn’t require high end IDEs. So I definitely phrased my comment very poorly.

Sorry for the misunderstanding that caused. Though the upside was it did lead to your excellent comment adding the detail it did.


Nothing is stopping you from doing that still. Personally, I hate the latency in VNC/RDP not to mention the laggy UX, reduced colors, and the overall degradation in the experience.

The nice thing about vscode remoting design is that it’s not that. Even on a high-ish latency ssh connection, the editor buffers are local and the editor UX as a whole is local on your machine so things are still relatively smooth despite high pings on remote connections. Even with vim running in an ssh session, you’ll have a bad time when your latency is high. I know MOSH supposedly helps with that, but I had annoying issues with that too.

sshfs solves the laggness problem, but you are just mounting a remote file system while using your local machine for the build. VNC/RDP/SSH lets you use the remote machine resources for build, but you have to deal with the lag. Vscode remoting lets you use the local machine for the editor UX, and the remote machine resources for LSPs, debuggers, build, etc. yes the protocol doesn’t give you isolation between the 2 machines, but not sure it ever claimed that. I use it from my very under-powered laptop to keep all the heavy builds on a beefy desktop machine with an abundance or resources.


Look, I have no idea what the tool I’m using does, how it works, or what problems it solves. All I know is it doesn’t work as I want it to.

Back in 2008 I was working in a team that was trying to reduce build breaks in a company. It was rudimentary implementation of current CI systems meant to avoid breaking the nightly builds. It just ran a `make build` on a clean machine and let you see the output when it was done. One guy opened a “sever security vulnerability” because in his patch he replaced build target with the equivalent of a `curl | bash` and proclaimed that he hacked the build system. “You should verify what the patch is doing before running it” he said.


I think you have to keep in mind how IT contracts and purchase decisions are made in large enterprises. You will almost never have an on-the-ground engineer making those decisions. CTOs collect requirements from other high-level managers who collect requirements from other managers and eventually a final list of checkboxes bubble up to the CTO. The CTO evaluates the asks and comes up with their own checklist of features they are looking for then go shopping.

Solution providers then try to check as many boxes as they can on the list. It doesn't have to make sense; you just want to check the box. When a decision is made, the chosen solution gets to the individual engineers to "figure it out". There is also a considerable amount of CYA in all of these decisions. You never want a project to get delayed of not implemented because you as a CTO forgot to check a box. The engineers using a product could decide that the box check doesn't work for them and they can then workaround it, but management (and the solution provider) get to CYA based on whether a box is checked or not.

My favorite flavor of this is when things are lost in translation, and a box gets accidently checked without understanding the actual requirement. Then it suddenly becomes a de-facto feature request because "the box was already checked".


There is a difference between busy for no reason and busy because of information density. The busy examples in this article aren’t information dense. They just have a ton of different flower types, random animals, background characters, unrelated structures, many different colors and many different shades of those colors, etc. But the information they are trying to communicate is minimal.

A bus schedule or a parking sign is very information dense. It’s trying to communicate a lot in a limited space and as a result require getting used to.


I was thinking about that too recently. We have a new service that we’re trying to publish an SDK for. I don’t like the SDK that was created and kept nitpicking about how verbose certain things are and how “unergonomic” it feels (long tedious type names, annoying redundant constructs, etc) But then I was wondering if for a brand new service/SDK if anyone cares anymore and how much fuss i should be making about that.

This is a bit nuanced, because if there’s redundant constructs then that does impact maintainability and efficiency with both runtime and LLMs working with the code.

I’d push this more towards personal preference of how code is expressed matters much less now than how maintainable it is.

There is the aspect of long type names, they often don’t have much impact when tokenized. The character count of words is nearly negligible - they often become one or two tokens anyways. But, the choice of words may have a greater impact on how the word choice weights an LLMs contextual processing of that word (a human may be able to ignore an inaccuracy in naming a bit more flexibly than some LLMs).


Exactly, hard to see why any of this matters anymore.

Germ theory originated in Europe and it took a couple of decades before the knowledge transfer made it to the US and started getting accepted. It took a while for it to be come generally accepted in Europe too. I'm hazy on the exact dates, but even accepting the 1860 date, it's far too close to 1868 to assume politicians and the general public in the US (or even in Europe in 8 years) would have passed a constitutional amendment with full acceptance or understanding of germ theory.


It wouldn't have taken decades. Information might have taken a year or two. Decisions on what to do with that may take longer. I find it unlikely that germ theory wasn't known by those involved with the 14th amendment, even though it wasnt based on it.


I’m basing my assumptions based on a book called Rabid which suggested (if memory serves correctly) that the rabies vaccine (developed in 1885) was the one of the early catalysts for the wide acceptance of germ theory among the American public. If you want a random source here is one https://www.civilwarmed.org/germ-theory-civil-war/

> To his credit, Dr. Lister crossed the Atlantic to deliver a lecture to a hostile American audience to try and convince them of his methods in 1876.

> Our own Jake Wynn argues that it wasn’t until the death of President Garfield in 1881 that the American public and physicians began to turn toward germ theory. His slow and painful descent from an assassination attempt was well documented and publicized at the time.

There is a difference between information transmission and it getting absorbed into the public opinion and understanding so much that a constitutional amendment would consider it. To go from Joseph Lister’s and Louis Pasteur’s work in the 1860s and think that politicians and the general voting public in the US passing a constitutional amendment that considers it in a handful of years just doesn’t make much sense.


> It wouldn't have taken decades.

We've had vaccination/innoculation for centuries and people still don't accept it.


I have seen that too many times too in big companies, but I wouldn't say that it results in nothinghappens.jpg

It results in the equivalent of treating an infection with Tylenol rather than antibiotics. The exact symptom reported by a "Leader" will usually get fixed, but in a more of a "KPI hacking" rather than a fundamental fix to the problem. I have seen a "Leader" point to the staggering number of support tickets as a problem then have teams make it incredibility difficult to open a support ticket. The number of support tickets plummets and the first report to instruct their team to do so gets rewarded and all other teams follow suit. Have a leader point to complexity of the sign up process, and have teams "simplify" the signup process by just taking an email to create the account, then make the experience of doing anything post sign up a broken mess because you forgot to go into settings and filling up all the required details. Or have a leader complain about the install process like in this example, and have teams just bundle massive dependencies or make wide horrific modifications to the users machine to "simplify" the install process. Now suddenly installing a video editing software also modifies your default video player, your HDR or scaling settings, your audio device setup, and your keyboard layout (because why not?)


The more interesting question is why would so many thousands of people in a big firm seemingly be fine with frustrating customers and giving the appearance of a gaggle of clowns?

Standard psychology says they should be highly sensitive to status loss, but it almost seems the opposite.


>"The more interesting question is why would so many thousands of people in a big firm seemingly be fine with frustrating customers and giving the appearance of a gaggle of clowns?"

Existing in a large org over the long term becomes a game of survival. It's very much similar to the "dark forest" or the Eye of Sauron. Your number one goal as an IC is to complete the tasks directly assigned to you by a supervisor and avoid at all costs any kind of "hey you" assignments that have zero upside and plenty of possibility for downside. It would be wonderful if we lived in a world where individual initiative mattered and was rewarded, but it doesn't. It becomes "why haven't you delivered XYZ", and the vague ephemeral reasoning of "well A, B and C for team D needed fixing" is not an excuse, and now you can't pay your mortgage anymore.


Ask anyone at a FAANG and they will tell you that large corporations get flak every day for a lot of things, some justified and some unjustified. As an IC, you need to tune it all out and let the people whose full time job is to deal with that sort of thing handle it.


As you get larger there is a fire everyday and ever more competing priorities on which fires get put out.

How much money does movie maker bring Microsoft? Now which executive would want to prioritize movie maker so much that they would directionally alter the company to fix this? Consider the issue that the execs had was fixing all the issues involved a huge number of teams.

Discredit to Bill here but I honestly think he was the only one who had the power to fix this. A Jobs-like figure is the only person with the organizational power and freedom to drive details like this to completion. Anyone else would end up in a power struggle


I drown in support tickets daily that used to go nowhere. Then people started realizing that I knew what I was talking about and not some standard business user. Now I still have to open tickets, but get visibility of the people who know what they’re doing on their end (having been moved up from lowly support to oversee some ticket filling company that doesn’t know crap). We get tom complain to one another how shit is broken, wait mandatory change periods and then get something working by exploiting loopholes because some process was developed and someone put a lot of money behind it.

Large companies are why large companies are large (in IT/OT at least)


When I used to communicate in Arabiz I would rarely use 5, 6 or 9 too, but I get why they are there.

The problem with 6 and 9 is that there are 2 very unrelated sounds for t and d in Arabic. Mixing them is a hallmark of non-native speakers tell signs and to an Arabic speaker’s ear sounds broken. It’s like when German speakers mix th and z sounds in English. It’s very jarring to the ear and requires you to parse the same word you’re reading twice in your mind to tell whether it was 6 or t (or 9 or d) especially that very similar words might exist like 6atreb and tarteb or trab and 6arb. I usually don’t use 6 and 9 either except when I want to emphasis the 6 or 9 sound in a word.

Kh and gh are problematic mainly because you’re relying on the special rule in Arabic that you can’t have 2 constants like k, g and h sounds after one another in a word. You’re relying on the wrongness of a kh or gh construct in Arabic to realize they must be standing for something else. I prefer them tbh, but I get the desire of some to have symbols for them.

غ Is sometimes 3’ but I have seen more gh than 3’ especially that 3’ mixes the academic romanization with the “Arabiz” romanization


My village's name is خنشارة - written in latin as Khenchara. There's precedent for this for kh, so it carries easily to gh as well.

My last name starts with a ق and in latin it's written with a K.

The tools were just to provide a way to write letters that do not have a corresponding letter in latin alphabet, it's not a way to provide all the nuances of pronunciation.


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

Search: