Why Linux is unhackable

Prajinvenkat

Member
Joined
Aug 22, 2025
Messages
37
Reaction score
11
Credits
343
Why linux is mostly unhackable ?
and also MacOS also unhackable why ??
all windows linux and macos are just OS but windows is mostly hackable
why windows not use Linux or MacOS strategy
 


Linux is very much hackable. Just the past 2 weeks there were found 3 different critical vulnerabilities. I can't recall when there were found so much holes. Remember to keep your Linux computer up to date. Fixes are usually there very fast.
 
Why linux is mostly unhackable ?
and also MacOS also unhackable why ??
all windows linux and macos are just OS but windows is mostly hackable
why windows not use Linux or MacOS strategy
Exactly! Just toggle unhackable=true in settings in Windows and boom, no more hacking, ever. Why Microsoft never thought about this?
 
Exactly! Just toggle unhackable=true in settings in Windows and boom, no more hacking, ever. Why Microsoft never thought about this?

C'mon now. We all know the ultimate protection to ensure Linux is God Tier unhackable.

1778822157321.png


But, you must ensure to set up cron job to execute on boot; otherwise it doesn't work...


Disclaimer: Just dont... If you don't understand linux, you won't be able to fix it. If you do; you're probably laughing.
 
You haven't been following the news lately?

 
And bro thought Linux unhackable! Such a violation.
 
I've spent part of the past however many years on this site telling people that Linux is not a secure operating system.

It is more secure than some other OSes out there, or at least has been through much of its history. But it is far from secure.

You can take steps to make it more secure. You can be security-aware. But it will never be free of exploits -- until some perfect entity makes it so. Given that we lack a perfect entity, security is going to be a problem well into the future.

One of the key differences is that Linux is FOSS. You can, if skilled enough, read the code to find exploits. As Linus' Law says, "Many eyes make all bugs shallow."

If you think Linux is secure, just use this site. We have a 'security' section. It doesn't show up in 'new', but it does get constant automated security notices. There aren't many days that go by that it finds nothing to report.

Linux is full of security holes. This is why it's important to keep your system updated.
 
I think It's more secure for the most part because less people target the Desktop. (at least for us- server wise it's still targeted often) If it was more used as a DT, it would make more people make more malware targeting the DTs for it.
 
Last edited:
C'mon now. We all know the ultimate protection to ensure Linux is God Tier unhackable.

View attachment 31871

But, you must ensure to set up cron job to execute on boot; otherwise it doesn't work...


Disclaimer: Just dont... If you don't understand linux, you won't be able to fix it. If you do; you're probably laughing.
1779981070748.png


what does this image means?

" Life is :(){ :|: };: "

is it a meme or something?
 
Okay - I know this is a video which requires an attention span, and despite its clickbait, it is insanely interesting and the creator does an amazing job illustrating points. It's about the XZ Utils Backdoor.

 
View attachment 32097

what does this image means?

" Life is :(){ :|: };: "

is it a meme or something?

It's a fork bomb. Think of it like a recursive process generator that very rapidly overloads your system until it's bricked due to resource starvation. With this particular one, a reboot might clear it up. Hense why I joked about ensuring it was set up as a cron job to execute on boot; effectively putting the entire system into a dead lock.

The life is forkbomb is just my little way of saying I think life is pretty much inherently doomed. As everything we do in life is essentially a slow burning fork bomb. It's a cynical take on life.
 
View attachment 32097

what does this image means?

" Life is :(){ :|: };: "

is it a meme or something?
As @AlphaObeisance wrote in post #14, the fork bomb will use up resources in a system to the point that the system bricks.

The fork bomb replicates itself using up the number of processes that a user can run on the system, which locks out the user from running any more processes, and on its way, its consumption of processes also uses up RAM and the caches on the system and generates huge cpu activity as it keeps flooding the system with itself. The user is thus unable to do anything and the system is overwhelmed by processes so it eventually locks up. That's basically it, in a non-technical nutshell.

It's possible to implement some preventative measures, but it depends in part on how a system is used. One can check on the number of processes that a user is limited to, since if the user is limited to a smaller number of processes that they are able to run on a system, the system will stop running user processes when that number is reached, and bash will output a message like:
Code:
bash: fork: Resource temporarily unavailable
Rather than locking up the system bash will lock up the fork bomb process.

To find out the number of processes a user is limited to one can run the following:
Code:
[~]$ ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) 0
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 39
file size                   (blocks, -f) unlimited
pending signals                     (-i) 62263
max locked memory           (kbytes, -l) 4194304
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 95
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 62263  <-------------MAXIMUM FOR USER
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited
The output shows that the maximum number of processes a user can run on this machine is 62263, which is more than enough for the uses that this particular machine undertakes. To see the current number of processes actually on the machine in the present moment, the user can run:
Code:
[~]$ pgrep -wcu $USER
971
pgrep identifies processes, "-c" counts them, "-u $USER" applies the pgrep command to the $USER, and the "-w" counts the threads of processes, which are actually processes themselves and count as real processes for the process tally that the user is using. The output on this machine is a mere 971 processes running which is well within the maximum limit.

The system itself, which includes root's processes has a much higher limit for the number of process it can run and can be seen with a command like:
Code:
[~]$ cat /proc/sys/kernel/pid_max
4194304
That figure is the same as "max locked memory" in the earlier ulimit -a output.

The upshot is, that for a user, one can lower the maximum number of user processes which would limit the fork bomb to that number, which, if low enough, will prevent the blockage of the system for the user. A number like 10000 might suffice, but as mentioned above, it depends on what the machine normally does. The best prevention is not to run a fork bomb.

One can configure the limits for user processes in the file: /etc/security/limits.conf, with instructions in the file itself and/or the manpage for ulimits.conf.
 
Last edited:
if linux were unhackable. if it were impenetrable by "programmers". the "jargon" file would have been half as long. or it would have gotten more "fear and loathing" entries. than ibm and microsoft combined.

if linux were unhackable. but unix were, according to "unix haters manual". we would be using unix instead today. deal with something much worse than "systemd". that the "systemd" haters would have to think hard about. get rid of one monster. to invite another. "because i just want to use it. i don't like maker of operating system spying on me."

linux might have been cut off from the start if it could be hacked. gnu would have said "no way!" no matter how desperate they were to have "their own" operating system. maybe i'm naive but there, i've said it.

i discovered long ago. internet explorer was very hackable. it affected me one day. so i hurried to buy and install anti-virus software. no need to explain further. but because i didn't know there was an alternative. to use which would have prevented me. from doing a lot of dumb things online.

i think someone already said it. but even macos is hackable. because i read in some other site. that the u.s.a. federal government or other country law enforcement agency. could get into it when they want to.

(shrugs) i use "qwant" as search engine these days. try "macos nsa backdoor" (without double-quotes) as search topic.

i noticed the op also started another topic of "is unhackable." i think they need to get a grip.
 
 
Y'know, there's degrees - and different definitions of! - "hacking".

When the word "hacking" comes up in our kind of circles, 99% of people automatically assume the subject matter is bad actors hacking the kernel or leveraging low-level system vulnerabilities, i.e, malware.......and criminals trying to steal or ransom your data.

I notice this entire thread has - naturally! - immediately (and predictably) gone straight off down the usual well-worn rabbit-hole. Again.

(This IS understandable, given that such exploits constantly grab the headlines whenever they appear.....and most of us are attuned to this kind of thing).

BUT:-

Say you grab a chunk of code from Github or Gitlab, or perhaps an entire small project that takes your fancy. You look through it, like what it does, but perhaps want to make some changes before compiling/running it. Well, that's "hacking".

Or - like us in Puppyland, where the entire OS is there to be played with, pulled to bits and/or rebuilt - as "hobbyists", virtually everything that's produced by community members is freely distributed & subject to whatever modification(s) the user feels like implementing. This, too, is "hacking".

Merely examples, but I thought it might be useful to point out that there ARE two sides to the same coin.

Just sayin', of course...


Mike. ;)
 
Last edited:
I notice this entire thread has - naturally! - immediately (and predictably) gone straight off down the well-worn rabbit-hole. Again.
It was because how the OP was titled, the title didn't give any indication of meaning something differently. Anybody can add(hack) their own code to the kernel locally and then compile it, to then run it.
 
Say you grab a chunk of code from Github or Gitlab, or perhaps an entire small project that grabs your fancy. You look through it, like what it does, but perhaps want to make some changes before compiling/running it. Well, that's "hacking".
Indeed "hacking" is broad, it's often used in open source community to refer to modifying code that's otherwise considered difficult to modify, such hacking a compiler or hacking the kernel etc.

If one is able to do that they're as well able to modify the code for malicious purposes as well, there's really no difference, same thing but different goals.

But so few people know about this.
 


Follow Linux.org

Staff online


Top