H4ZB7

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

Comment · 2 years ago

why is this absolutely oblivious, joke of an article voted so high? web browsers are bloated and insecure, and there is practically no difference between them. tor browser tries (keyword) to reduce fingerprintability to make tor actually work as intended, beyond that there is no difference between firefox. icecat, palemoon, and all those forks are just firefox with 0.01% of the bloat removed. any "privacy" or "security" plugin just increases your attack surface and makes your fingerprint more unique (and 99% of websites collect this fingerprint and use it).

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

Comment · 2 years ago

why do i have to be exposed to these people who don't have the slightest clue about how the computer works? i want out. i don't want to use an ecosystem that includes these people to be part of what runs on my computer. why would i want arbitrary web pages to be able to connect to all my daemons that expected that outsiders can't connect to them including stuff like X and god knows what else. it's bad enough that browsers can already connect to localhost which has already single handedly enabled hundreds of thousands of vulnerabilities in the form of "attacker's page (even with js disabled) accesses your local daemon from some 10th level nested iframe ad crap"

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)

Comment · 3 years ago

this isn't surprising, the author is just cowboy coding. i *expect* anything in un\*x to require 5 hours for first reading the man page (which the article has shown to be useless, informal, and idiosyncratic - making it worse than nothing - in this case, which isn't surprising either) then conducting an investigation into weather the behavior is portable. now you know why real programmers hate un\*x - it's actually bogus garbage that only charlatans can grasp. just the cowboy programmers like it because they can feel like they're doing something when they're actually just making errors everywhere.

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

Comment · 3 years ago

looks like an absolutely uninteresting boomer language, by the fact that it just shows standard imperative stuff followed by "wow it supports unicode, we are up to date"! (which is a misfeature, btw, i like being able to audit my code before running it (not that thats possible in the current mess of misconceived computers but yeah still it would be good to start doing things in the right direction).

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

Comment · 3 years ago

why do people write articles about go features? when PHP was in its prime, almost nobody wrote blogs explaining how they found some philosophy in PHP. there's a reason for that.

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 other example of memory unsafety in go being that modifying slices between threads can lead to actual memory corruption, not just simulated memory corruption as above

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

Comment · 3 years ago

> something something privilege

> 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.