31 karma · joined January 13, 2023
translation:
> how we are advancing the police state or some bullshit. btw this is good for security and privacy
didn't read, not that i've ever read or used anything that has come out of myspace 2.0 anyway.
/usr/sbin/./././some_admin_tool
/usr/sbin/../sbin/../sbin/some_admin_tool
/my_rigged_folder/haha (using symlink)
but i guess it would have required allocating a string or something which may have mattered 40 years ago even though we could have had a better OS in every way 20 years ago
and the same for the process list (in multiple ways, one you can see other people's passwords if they do HISTFILE=/dev/null something --password password, two you can just modify the process list)
and i get the last laugh because un*x lovers will reply to criticism such as "your CLI shit is retarded it logs the passwords to disk" with "NO BRO I USE HISTFILE=/dev/null" to which i reply "that's a lot of shit to type just to not log your password to disk" to which he replies with "NO BRO I USE SPACE PREFIX" and he's still wrong due to previous paragraph. similarily the un*x lover will boast about how he can detect malware / bad guys by using the process list yet nope it can just be bypassed like anything in un*x.
and don't even get me started with how moronic it is for a CLI program to "prompt" the user for a password to avoid this issue (actually you can use patches to make CLI paramters not shared to all users of the system, which is still stupid because none of that type of information should ever be shared in he first place: no other user's process should see any attribute of mine)
and the icing on the cake is the typical way people inside the industry are completely oblivious and say "no man this is actually amazing stuff here"
> It's possible to write extremely powerful tools using shell scripts, and modularize your code. Bourne shell doesn't provide a clear mechanism for referencing relative files. By establishing a command file's base dir, you can reliably reference relative shell scripts.
wow a turing complete language is powerful who knew now if only we had one that wasn't just a cesspit of footguns most of which are there for no real reason and even historically were still invalid
browsers are bloated and unfixable. consuming "privacy" and "security" products does not fix this.
> Mullvad Browser: Best Built-in VPN Support
this text is literally written by a bot
i want out of this community. all these little people who have zero contextual understanding always requesting and implementing these features at all costs as long as the idea exists. this is a un*x problem at the core: if a feature conceptually exists, we must implement it at all costs. and another un*x problem here is having a global namespace (tcp port numbers) that things are just exposed to everything (either localhost or the network) by default when they could have easily just used an opaqaue handle that the machine operator can copy and paste into whatever application he wants to use it (no some openauth type shit that failed to be secure for 15 years is not what i have in mind)
lol im just gonna leave those typos (automatically double escaped asterixes) there which were caused by writing this comment on a non logged in page after logging in on a different tab. perfect example of the same string flinging garbage
its interesting that there is supposedly an os in oberon that actual uses the same language for the shell or something or the kernel is written in it or something like that but this page just makes me think its not worth looking into after all
when you see someone open their article explaining a language feature by talking of the implementation details or specific use cases, that's a language smell (of course all industrial PLs stink).
ironically go is the only post 80s language that uses "memory safe" as a marketing point (even though they all are), yet go has the most memory unsafety of post 80s industrial languages. you can parse something and pass on a slice somewhere. if you mistakenly slice that slice with a bigger size - this incorrect size being the programmer bounds check error - you restore some of the original array that was supposed to be cut off and teh next operation working on that slice will thus modify or leak data:
package main
import "fmt"
func main(){
a := [3]int{1,2,3}
b := a[0:2]
fmt.Println(b[1])
c := b[0:3]
fmt.Println(c[2])
}
$ go run a.go
2
3
the point here is that this footgun doesnt even have a real point outside of some insane performance argument. nobody would ever design something like this without massive cognitive dissonance (aside from industrial PLs, which just copy and modify the previous industrial PL, C in this case). all go's primitives are rigged like this with unintuitive behaviors. its amazing how much such a simple language with small scope can get wrong. and i expect nothing less from people who go around saying "zeroeth". DAY OF THE BOBCAT SOON
> text only i'm a big guy now
> no indication of what this group actually was unless i perhaps read every paragraph
> i liked the thing because of camaraderie
now you know why the hacker scene was always garbage. and internet forums. it's all mediocre people who are just there for camaraderie and jerking each other off over these false virtues.
you are designing the fabric of a medium where the main use case is to open 20 pages at once from completely random strangers across the internet. OBVIOUSLY it should not autoplay sound by default.
(also the same reasoning explains why JS should not be a thing, because it slows everything down and causes bugs by letting casuals design the fabric instead of the browser just coming with what's needed (you'd think they can do this with trillions of man hours))
if i was to implement a browser that could properly render CSS for some given set of real life scenarios i would be getting back to you in 100 years. paying tax, banking, trading academic literature should not rely on a magazine formatting jenga puzzle
imagine someone pitching shell programming today. the response would be: LOL so you mean each language will have a common subset of syntax that supposdely works the same across all of them? how can anyone ever program that way?
* ironically, a big part of why embedded products are so flaky is just because of their shell scripts
also the OOP paradigm makes no sense and is just pseudoscience. i can't even think of a valid reason to use objects once you get past the cat/dog/animal example which only makes no sense because the proposed problem has no concrete requirements. there are no small examples where objects make sense, and for any big example it would require days of analysis to reach a conclusion. there are lots of invalid reasons, like some syntactic convenience of x.fff().zzz(), this example being invalid because that syntactic benefit can be better achieved by a composition operator like in bash: x | fff | zzz
if i look at any OOP codebase the first thing ill see is someone pointlessly loads up some data into an object and calls obj.method() which then just unloads the data as if they were just parameters to that function. why did you even make the object in the first place? because OOP braindamage, simple. you've been trained that this is somehow the ethically correct way to do things.
the idea that objects provide some new type of abstraction is just nonsense. those constructs were already doable in ML as well as by convention in C or any imperative language, which is how most such languages are in fact written. all OO adds is interfaces which are done better by many other languages, and inheritance which is just a joke.
https://ultimateclassicrock.com/john-lydon-death-penalty-sex...
give me functions that output typed data. none of this string parsing shit. the sole fact that they have syntax to call bash: $() makes me not want to use this ever. this is why every single effort like this is wasted. i used to get excited by these projects and after about 2 of them i realized it's always a bunch of crap duct taped together, and also bends over to be compatible with un*x and so everything is ruined.
they're also often so poorly implemented, like with those early fancy python shells they'd go beserk if one command you execute goes into a time consuming process (or infinite loop) whereas why the hell can i not just run another command below while waiting for the one above to complete? this is the thought i had in 2008. i could have made something better out of my ass. really, there's no other way to put it.
here's another thing: a language console should operate on semantic objects, not text. as in, you move objects around to program in it. editing code by typing one character at a time is too slow. no amount of vim or emacs fixes this. in fact, we can just scrap those un*x garbage (along with the rest of un*x) while we're at it, when implementing an OS that works on actual meaningful data instead of text, and semantic objects instead of a language represented by text.
it's literally longer than reading the Go spec and even after reading it several times i still can't code bash
yes, because the mere act of comparing two variables in bash is about 100x harder than any other language (not to mention it literally straight up adds undocumented RCE vectors to your code for example when you use [[...]])
- piping isn't anything special, its just an operator
- piping has like 10 different things you need to account for, just a bunch of stuff is chosen FOR you (heuristically) in the shell. for example IFS. whether its correct for a given pipeline is an entirely different question
- any form of error handling in a pipeline is a syntactic disaster mostly because shell syntax completely sucks
- every second program in the pipeline will literally just execute code from the input until you figure out the secret option to make it not do that anymore
- data has a structure, whether you think it does or not. whenever you fail to account for all possible cases (doesn't help that these tools mostly don't have any specified format) of that (such as in most shell scripts), you are opening holes for bugs. both sides of the pipe must use the same data structure (and since its shell that means encoding it to text which changes depending on your locale and encoding).
- for most cases you don't even need pipes:
a = f()
g(a)
or just g(f())
piping is just premature optimization like lazy evaluation. composing functions is actually simpler, just shells have no (good) way to do it.