• 0 Posts
  • 489 Comments
Joined 2 years ago
cake
Cake day: June 16th, 2023

help-circle
  • One day boss comes in and sees my colleague. Remarks how early he came in. He said he never left the previous day and planned to just keep working (salaried guy). Boss said he needed to take the day off, wouldn’t have him drive, and he drove his car and had me follow to take the boss back to work after dropping colleague and his car at home.

    He consistently tried to break that guy’s incessant overworking. Had a lot of respect for him.

    Unfortunately he got canned when he kept some stuff from upper management in writing that got upper management in trouble. Not enough trouble to remove their ability to retaliate, but enough to save a few other jobs of folks they were trying to throw under the bus for their mistake.


  • I had been planning to, but being lazy about trying to enable my IDE setup but was giving it the benefit of the doubt. Your feedback resonates with how much I end up fighting auto-complete/auto-correct in normal language and seeing it potentially ruin current code completion (which sometimes I have to fight, but on balance it helps more than it annoys). I suppose I’ll still give it a shot, but with even more skepticism. I suppose maybe it can at least provide an OK draft of API documentation… Maybe sometimes…

    On the ‘vibe coding’, on the cases I’ve seen detailed, it seems they do something that, to them, is a magical outcome from technologies that intimidated them. However, it’s generally pretty entry level stuff for those familiar with the tools of the trade, things you can find already done dozens of time on github almost verbatim, with very light bespoke customization. Of course there is a market for this, think of all the ‘no code’/‘low code’ things striving to make approachable very basic apps that just end up worse than learning to code. As a project manager struggles to make a dashboard out of that sort of sensibility, a dashboard that really has no business being custom but tooling has fostered the concept that everyone has a snowflake dashboard, it’s a pain. But maybe AI can help them generate their dashboard. Of course, to be a human subjected to the workflows those PMs dream up is a nightmare. Bad enough already at my work there are hundreds of custom issue fields, a dozen issue types, and 50 issue states with maddening project to project unique workflows to connect the meaning of all this, don’t like AI emboldening people to customize further.

    The thing about ‘vibe coding’ is when they get stuck and they get confused/frustrated about why the LLM stopped getting them what they want. One story was someone vibe coding up a racing game. He likely marveled as his vision materialized. From typing prose without understanding how to code he got some sort of 3D game with cars and tracks and controls. This struck him as incredibly difficult otherwise, but reachable through ‘vibe coding’. Then he wanted to add tire marks when the player did something, maybe on a hard turn) and it utterly couldn’t do it. After all the super hard stuff, why could the LLM not do this conceptually much simpler thing? Ultimately spitting out that the person needed to develop the logic himself (claiming it was refraining to do it because it would be better for him to learn, but I’m wagering that’s the generated text after repeated attempts to generate code that the LLM just could not do).




  • I occasionally check what various code generators will do if I don’t immediately know the answer is almost always wrong, but recently it might have been correct, but surprisingly convoluted. It had it broken down into about 6 functions iterating through many steps to walk it through various intermediate forms. It seemed odd to me that such a likely operation was quite so involved, so I did a quick Internet search, ignored the AI generated result and saw the core language built-in designed to handle my use case directly. There was one detail that was not clear in the documentation, so I went back to the LLM to ask that question and it gave the exact wrong answer.

    I am willing to buy that with IDE integration or can probably have much richer function completion for small easy stuff I know to do and save some time, but I just haven’t gotten used to the idea of asking for help on things I already know how to do.



  • I understand it fine, and it’s not just a packaging phenomonon, all sorts of software developers have stopped trying to have consensus on platform and instead ‘just ship the box’. 99% of the time a python application will demand at least virtualenv. Golang, well, you are just going to staticly build (at least LTO means less unrelated stuff comes along for the ride). Of course docker style packaging is bring the whole distro. I’ll give credit to snap and flatpak that at least allow packaging to have external dependency packages to mitigate it somewhat.


  • I’d say actually a bit of the opposite. Generally speaking we don’t need a new package manager or init system, and better hardware support is almost entirely a kernel concern (one might make an argument that the loose bits of key management and tpm2 tools and authentication agents could be better integrated for “Windows Hello” type function I suppose, but I doubt that’s what the meme had in mind.

    Not really needing to reinvent the wheel on those, we got a variety of wheels, sometimes serving different sensibilities, sometimes any difference in capability went away long ago (rpm/dnf v. deb/apt).

    The best motivation I can think of at this point is to make specialty distribution that is ‘canned’ toward a specific use case. Even then it’s probably best to be an existing distribution under the covers. I think Proxmox is a good example, it’s just Debian but installer made to just do Proxmox. You want to do automated installation? Just use Debian and then add Proxmox (the official recommendation), because they have no particular insight on automated deployment, so why not just defer to an existing facility?

    The biggest conceptual change in packaging has been “waste as much disk as you like duplicating dependencies to avoid conflicting dependencies”, maybe with “use namespace and cgroup isolation to better control app interactions” and we have snap, flatpak, appimage, and nix very well covering the gamut for that concept.

    For init, we have the easy to modify sysv init, or the more capable but more inscrutable systemd. I don’t see a whole lot of opportunity between those two sorts of options already.







  • Like I get and appreciate the CLI and for networking, that’s pretty much all I’m using anyway, but I am shocked that enterprise networking doesn’t even bother to do any GUI. Once upon a time Mellanox Onyx bothered to do a GUI and I could see some people light up, finally an enterprise switch that would let them do some stuff from a GUI. Then nVidia bought them and Cumulus and ditched their GUI.

    There’s this kind of weird “turn in your geek card” culture about rejecting GUIs, but there’s a good amount of the market that want at least the option, even if they frankly are a bit ashamed to admit it. You definitely have to move beyond GUI if you want your tasks to scale, but not every engagement witih the technology needs to scale.


  • While you don’t need to memorize button locations and menus, the frustration is that it takes longer, and memorizing those details slightly mitigates. It’s torture helping someone do something while they hunt for the UI element they need to get to the next level of hierarchy. They will do it, in time, but it just feels like an eternity.

    The main issue in GUI versus CLI is that GUI narrows the available options at a time. This is great, for special purpose usage. But if you have complex stuff to do, a CLI can provide more instant access to a huge chunk of capabilities, and provide a framework for connecting capabilities together as well as a starting point for making repeatable content, or for communicating in a forum how to fix something. Just run command “X” instead of a series of screenshots navigating to the bowels of a GUI to do some obscure thing.

    Of course UI people have generally recognized the power and usefulness of text based input to drive actions and any vaguely powerful GUI has to have some “CLI-ness” to it.


  • I suppose the point is that the way people interact with GUIs actually resembles how they interact with CLIs. They type from memory instead of hunting through a nested hierarchy to get where they were going. There was a time when Desktop UIs considered text input to be almost a sin against ease of use, an overcorrection for trying to be “better” than CLI. So you were made to try to remember which category was deignated to hold an application that you were looking for, or else click through a search dialog that only found filenames, and did so slowly.

    Now a lot of GUIs incorporate more textual considerations. The ‘enter text to launch’ is one example, and a lot of advanced applications now have a “What do you want to do?” text prompt. The only UI for LLMs is CLI, really. One difference is GUI text entry tends to be a bit “fuzzier” compared to a traditional CLI interface which is pretty specific and unforgiving.


  • In a pretty high end high tech company, there’s still lots of people who see a terminal and think “ha hah, they are still stuck in old mainframe stuff like you used to see in the movies”.

    My team determined long ago that we have to have two user experiences for our team to be taken seriously.

    A GUI to mostly convince our own managers that it’s serious stuff. Also to convince clients who have execs make the purchasing decisions without consulting the people that will actually use it.

    An API, mostly to appease people who say they want API, occasionally used.

    A CLI to wrap that API, which is what 99% of the customers use 95% of the time (this target demographic is niche.

    Admittedly, there’s a couple of GUI elements we created that are handy compared to what we can do from CLI, from visualizations to a quicker UI to iterate on some domain specific data. But most of the “get stuff done” is just so much more straightforward to do in CLI.



  • Could keep all of them that don’t have annual fees, and spread out your purchasing. I have three cards, one that’s 2% off everything, and one that’s more off food, and another that’s more off online purchases. My aggregate credit limit is pretty high even if each one were a bit modest (they aren’t as modest as they used to be though)

    You can always pay off your balance more often than monthly. When I first opened my first card, I paid it off every Friday, to make sure the small limits were available if I needed them (I had a credit limit of $1,000 back then). Now I pay them off every payday, still multiple times a month. If you need to carry a large balance across payment cycles, you’ll get stuck on a high interest rate treadmill you don’t want to be on anyway.

    The credit limits increase with time. The $1,000 card I started with now has a $10,000 limit. Mostly the limits came automatically, but I did request an increase to be able to pay for a home repair in a single transaction. Now between the three cards I have a lot of limit.

    A fair number of places where you might want to spend a lot of money in a single transaction won’t accept credit cards anyway over a threshold. Last time I bought a car after establishing the price I asked about just charging it to a credit card. They were willing to do it only for $2,000, so I had to cut a check for most of the car anyway.