Hacker News new | past | comments | ask | show | jobs | submit | rigelina's comments login

You'd think that, but I had an auditor that had guidance requesting confirmation of security cameras on the servers. They wanted to drive to the AWS data center to see the cameras. If the drives got stolen, you'd better make sure AWS shares that video with you.


Ok, but what if someone bypasses the cameras on your servers with looped footage? Did the auditor think about having security cameras on the security cameras?

Amateurs.


Have they never seen Speed?


This was my introduction to K3s as well. RPis running K3s with enough resources left over to actually do some small tasks. I hosted a small data pipeline that analyzed trading data from an MMO. It was as fun as it was impractical, and I learned quite a bit.


I can't tell you how many times I pipe in rev to put my text where I want it for cut (then rev it again).

Abbreviated example, getting the service names from a k8s cluster looks roughly like (actual command does a bit more processing):

kubectl get deployments -o wide | rev | cut -d'=' -f1 | rev

But if it's just gobbling whitespace, xargs without a command can be your friend.

$ echo "key: value" | cut -d: -f2 | xargs

value

My brain generally goes "rev sed head tail xargs cut tr ... screw it, I'll use python ... someday I shall learn awk." There's a young engineer on my team that knows awk, and I'm envious.


Neat, but both your tricks (rev and xargs) are more for getting the last word than getting the nth word.

For the sake of the argument, say I have the following fixed output and want the sizes:

    $ ls -l
    -rw-rw-r-- 1 userAAA group      588 Aug 29 00:25 file1
    -rw-rw-r-- 1 userAA  groupB   11870 Aug 29 00:24 file2
    -rw-rw-r-- 1 userA   groupBB   1166 Aug 28 23:56 file3
    -rw-rw-r-- 1 user    groupBBB   195 Aug 28 23:56 file4
I would just do:

    $ ls -l | awk '{print $5}'


You don’t even need to know awk these days. Just say “how to do x munging task” in ChatGPT and you’ll get a one liner that will be just as good as if you’d say there squinting at man pages for 30 minutes


this is exactly the sort of case where you get non-portable bullshit you don't understand out of it! It spits out something that works on BSD but not on GNU, you put it in your script and _boom_ wonder why the thing blew up in prod, and oh btw you also lack the ability to debug it because you never understood it in the first place


Meh, I don’t think that is a problem endemic to shell specifically. That’s more of putting untested code in production. The thing about the fact that is a one liner is… if that happens and it’s not portable, who cares? You just turn around, paste that sucker back in, and say make it work on OsFlavor2.06 and you get back something that works. You don’t even have to fully understand why it isn’t portable, you can just ask the AI and have it explain why. If you wanted something battle tested in prod that was readable and understandable you wouldn’t be using one line shell scripts in the first place, regardless of whether they were written by an AI or not


More importantly it's just mega slow.

The whole point of bash one liners is not to write short bash, it's to type it in your shell to get a result quickly.

Just typing the url to chatgpt in my browser I would have had the time to write my one liner in she'll XD


I sincerely doubt unless you are writing shell all day every day that you will get a decently complex working one liner out faster than GPT4.


Right, but you are bending the argument to your will.

What is a "decently complex one liner"?

If it's decently complex, then it's probably not a one liner, so indeed chatgpt may be faster.

If it's a one liner, then it's probably not complex, so I would be quite confident in being faster than chatgpt.

The reality is, 99.9% of one liners are just series of pipes and filters to extract specific fields from an output, and act on it. I'm quite confident I would be faster than chatgpt for any of these. And no, I don't write bash "all day, every day".

I tend to see "every day bash" as very similar to SQL. Once you know cut, grep, find, sed and awk, even at a basic level, then you can combine them and extract pretty much anything.


One example of what I call “decently complex one liner” that I had ChatGPT write the code for the other day is a command to find top n files of a given pattern in a certain directory, sorted by n in terms of most recently modified. Sure that is reasonably fast to write yourself if you know shell pretty well but why bother when I can just input my requirements and get something that immediately works without squinting at man pages and checking my patterns on regex101? In the time it takes to write out that two sectioned pipe command I’ve already solved it by pasting my requirements into the AI.

SQL is a great example too where I will use an AI even though it’s not necessary. I’ve probably written many tens or hundred thousands of lines of SQL in my life and I would still prefer to just toss my requirements into an AI and have it write the query for me so I don’t have to cross reference things and look up syntax. Easier to do that and iterate on it once or twice than comb through some bigquery or Postgres docs because I can’t remember that particular flavor of sql today


I've been out of grad school for a bit now, but 10 years ago is about right. There were a lot of things being published about compilers that might have well been direct ports of papers written in the 70s, "now for JITs." And honestly, if you read some of those papers from the 70s about automatic parallelization and such, it was pretty freakin' cool. And there were memory guarantees in Fortran that were not present in C that made it non-applicable. Java had most/all of those guarantees, which is what I think brought about their revival. That's probably not the whole explanation, as I'm not sure why it took Java so long (these were 2010+ papers, 15+ years after Java came out).


In this type of scenario, it's sometimes because there are two or more implementors that are trying to develop the standard in a way that makes their existing implementation compliant. Likely there were existing scripts that relied on the behavior being specific to that implementation, so it was explicitly made optional, which is viewed as better than not adding the behavior to the standard at all. "May" is just a polite standards way of saying "Warning: check yourself before you wreck yourself."


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

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

Search: