And the Unix filth did it. Without moving files to trash can. And there is no way to get anything back, because WORSE IS BETTER and the the shitty Unix unlinks everything even when filesystem has enough free space. Why? Why Unix cant die and be replaced with a good OS?
Name:
Anonymous2012-08-28 5:36
There is an undelete(char *path) syscall, but it wont work. Because Unix is fucking shit.
Name:
Anonymous2012-08-28 5:39
So you just did something and now you're complaining about it? You make me want to commit a hate crime.
>>3 you just did something
Nope. I didnt invented Unix.
Why there is no way to bury Unix,Linux and C/C++? The world will become so much better without them. Killing Unix is like extermination all the Jewish parasites or finding a cure for cancer - it will a major success for humanity.
Name:
Anonymous2012-08-28 5:47
>>4 You deserved it.
I doubt any user deserves a system that shoots him in the foot.
It's funny because since I first linked Xah Lee on here, some /prog/riders keep bashing UNIX and Worse is Better. But yeah, UNIX is shit and GNU and Windows are only barely less evil.
>>7
The problem with flame posts such as yours is that they don't actually try to say anything interesting but usually reflect their own ineptitude. The message that I read goes along these lines: I have a problem and I am too inept to express why this problem is worth your time. Instead I'll just be vague, you're smart enough to know what the problem is.
Name:
Anonymous2012-08-28 6:09
>>7
Well, Windows too has unlink function and it will delete immediately, because it was written by the same worse-is-better faggots, who hate users and want everyone to suffer.
if you don't want to shoot yourself in the foot, then don't kill weeds using a shot gun. Use weed spray instead. But if by chance a wolf surprises you, you may have trouble fending it off with weed spray.
>>18 type command computer does as requested WHYYYYYY, I HATE THIS!!!!! 2012
ISHYGDDT
Name:
Anonymous2012-08-28 9:42
>>16 The problem is that you rewrite `rm` with a safe version only when you already shot yourself. I.e. your foot is already lost.
I added an alias for rm into a command that moves stuff to /tmp/trash when I learnt about it and before I deleted anything important, both feet are still present.
Name:
Anonymous2012-08-28 11:12
http://m.simson.net/ugh.pdf Unix is a computer virus with a user interface.
Unix is a toy OS, created to run a game in a few KB memory. It was a gimped single-user Multics. Any real OS moves the deleted files to a temporary area or has a way to restore deleted files. Even MS-DOS has better file recovery (UNDELETE). Windows NT has good parts, from VMS, and bad parts, from Unix.
Hey guys, I stabbed myself in the hand with a knife and it actually pierced through my hand. Therefore, I'm smart and whoever invented knives are stupid.
Any real OS moves the deleted files to a temporary area or has a way to restore deleted files.
Yeah, wasting several terabytes of disk space with stuff that I wanted to delete is a sensible thing to do.
Name:
Anonymous2012-08-28 14:56
>>25
There's also a way to permanently delete (purge) files. Only a shitty file system (sync; sync; sync) uses the first available space to store files.
Name:
Anonymous2012-08-28 15:06
Can you believe that there's no real OS that saves memory from RAM that was free'd by program, rather than putting it into a trash can for me to examine before, finally, being deleted to the OS trash can to undergo final examinations and then deleted if deemed necessary?
Don't play with daddy's tools if you don't know how to use them. Stick with you Microsoft toys, kid.
Name:
Anonymous2012-08-28 16:44
>>25
Modern flash storage devices will benefit from the circular first deleted - first overwritten scheme. Because there is a limited number of times one can write on a flash.
Name:
Anonymous2012-08-28 16:47
>>30
And, BTW, keeping alive filenames for deleted files will also extend SSD's live. So basically Unix killed my files and raped my SSD with needless writes.
>>31 So basically Unix killed my files and raped my SSD with needless writes.
The other day I put gas in my car so I can drive it. Then I began driving and my car started burning the gas. Whoever invented cars was an idiot. The gas should just stay in the tank so you can drive forever.
>>33
Same thing with hard drives. The OS should never write to the hard drive, because the number of writes are limited. That's why I don't eat food, because there's only a limited number of bites I can take before the food is gone. Eating food is a waste.
Name:
Anonymous2012-08-28 16:58
>>32
Like everything in the Unix World, unlink() works in the worst possible way.
As a rule of thumb: never ever invoke `rm` directly. Especially in your home directory.
Name:
Anonymous2012-08-28 16:59
>>33
That is why U.S. lost cart market with their enormous tanks, while Japanese won.
>>35
You're an idiot. I can rm -rf ~ and I'll be in perfect shape because I have backups. In fact, my home directory is synced across my Thinkpad, my EEEPC, my Mac, my headless in the garage, and partially to my EC2 server/seedbox and my account on my school's network.
Some of us actually know how to use our tools, kid. Go back to /g/ and show everybody your OMG customized Windows desktop.
Name:
Anonymous2012-08-28 17:15
>>38
Yep! When dealing with Unix you ought to do backups. A lot of backups.
>>39
Yes, because as you observed, hard drives fail after a finite number of writes. So what's your excused for not backing up? You think that AVD malware that keeps popping up and promising to protect you is going to shelter your from the harsh reality of hardware failures just like your mommy and daddy do from the ``real world''?
>>38,40
Agreed. UNIX™ is better because it wastes more time and makes me feel like a true UNIX hackerⓇ.
.
..:
Suck it, Win$hit faggots! Im better than U!
It's ironic considering the only time I ever use Windows is to help my roommates troubleshoot their performance problems. Not to mention the constant BSoD that was preventing my landlord from checking his email for three days.
Windows sure is a timesaver !
Name:
Anonymous2012-08-28 17:46
Dear All
Today I accidentaly removed my home directory which contains no. of other directories having my work done in last 3 years.
I used the command rm -rf * .
I am really confused as to what to do.
I looked for the problem in the google got some links pertaining to my problem, but got no solution.
zsh prompts me whenever I do rm *. It's pretty annoying, but I hardly ever do rm * because then I'd be left with a useless empty directory I need to get rid of.
Name:
Anonymous2012-08-28 17:52
>>50
Exactly! "rm *" is completely useless, yet Unix still allows it, just so you can you yourself in the foot.
>>51
It's not completely useless. If you're poking around in a cache directory and decide you want to empty it, rm * is exactly what you want.
Name:
Anonymous2012-08-28 18:01
>>52 poking around in a cache directory...
Yet another design flaw! System should clean its caches itself, when it needs space. I.e. if your webserver has a big log file and storage device is out of space, webserver should wrap log around. But no, a Unix webserver will just crash, damaging the log file in most cases and leaving database inconsistent.
>>51
Yes, Unix ``allows'' me to do what I want. Terrible ! I'd much rather use an OS that tells me ``no, you are no allowed to delete these files because you're probably just a mouthbreathing faggot who doesn't know what the fuck you're doing, like >>1-san ! How about a nice game of solitaire?''
>>53 Yet another design flaw! System should clean its caches itself, when it needs space.
Says the faggot who deleted his home directory trying to clear /tmp, which is managed by the system.
>>55 http://en.wikipedia.org/wiki/Three_Laws_of_Robotics
1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey the orders given to it by human beings, except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws.
>>53
It doesn't have to be a system cache. Programs have their own caches. It might be a program that you're working on (this is a programming board after all). If I'm working on a program and I change the schema of the cache files, I have to clear the old cache files by hand.
Name:
Anonymous2012-08-28 18:15
>>59 It might be a program that you're working on
The program shouldnt reinvent the wheel and just use system's cache API, the same way it uses unlink(), instead of writing directly to HDD, as many older programs did.
>>66
Why not write your own operating system? That way you wouldn't have to use a Unix clone, and we wouldn't have to put up with your whining about operating systems that actually do what you tell them to.
Name:
Anonymous2012-08-28 19:07
>>67
1. I wont find investors.
2. If I find investors, they will be Jewish and I dont want to deal with the Jews.
3. I dont want to spend my whole life, designing an OS. I have more fun stuff to do.
>>29,55
Typical Unixer responses. In the hands of a genius, even a toy like Unix can be useful. Most users aren't geniuses. Most Unixers aren't geniuses either (some just think they are). Unix is full of buffer overflows and gotchas because it was not designed to be used. It was designed to be played with. It's like building a car that falls apart on purpose to attract mechanics. Unix is for people who think it's better to fix other people's bugs in the OS than to work on their own projects, who think it's more fun to edit header files so they can get graphics drivers to work with their kernel than to play an actual game.
Name:
Anonymous2012-08-28 19:36
*THE* classic Unix horror story http://www.lug.wsu.edu/node/414
If these guys used VMS on their VAX instead of Unix, they wouldn't have had this problem.
>>73
If they used VMS instead of Unix, they wouldn't have had any files to delete.
Name:
Anonymous2012-08-28 20:13
http://en.wikipedia.org/wiki/ISAM http://h71000.www7.hp.com/doc/731final/documentation/pdf/ovms_731_rms.pdf
Do you know what else real OSes have that Unix doesn't? Indexed files.
A fast hash table or B-Tree as part of the filesystem, accessible by all programs. Some versions let you run SQL queries against the filesystem. Who needs to use text files as databases when you have an OS that makes handling binary files just as easy?
Name:
Anonymous2012-08-28 20:14
dubs GET!
Name:
Anonymous2012-08-28 20:16
>>70
Any serious commercial project needs investors, because it needs a ton of experts in different fields.
Name:
Anonymous2012-08-28 20:29
>>72
Typical Windowser response. Unix is just a toy. The entire internet and the web and the whole entire infrastructure that depends on Unix is just a really big toy. The billions of dollars that flow through Silicon Valley is just play money. All those high paying jobs that require Unix skills are just hobbies. But my vidya gayman machine is serious fucking business !!
Please just go back to /g/.
Name:
Anonymous2012-08-28 21:59
>>76 Who needs to use text files as databases when you have an OS that makes handling binary files just as easy?
Probably people who need portability across platforms.
>>90 Why aren't these highly educated/skilled/paid developers flocking to your glorious superior development environment?
Because Java++.
Name:
Anonymous2012-08-29 1:04
>>21
Windows NT doesn't provide special facilities for the ``Recycle Bin'' either. It's a shell construct just (un)like it is in Unix.
Name:
Anonymous2012-08-29 1:15
>>55 http://www.mcpressonline.com/operating-systems/ibm-i-os400-i5os/journal-management-on-the-as400.html The journal receiver-the container into which OS/400 writes its journal entries-is a true audit trail: no one on the system can manually modify its contents, so there's never any question about its accuracy. You can, however, display the contents of the journal receiver anytime. Inside, you'll discover a surprising number of different types of entries, including a time stamp, a user ID, a job ID, and (if the journaled object is a database file) a picture of the actual record after it was changed. You can also configure the journal receiver to maintain a picture of the record before the record is changed.
If you ran a server that contained anything valuable, what would you rather have: OS-level file journaling that protects against accidents and malevolence, or rm -rf * .oops? No malware for either OS/400 or VMS has ever been discovered in the wild.
>>93
OS/400's journaling and VMS' Files-11 are two very different things. What they have in common are (1) they aren't pure filesystems, and (2) they both have significant computational and storage costs. As long as you're muddying the waters, why not compare Oracle DB, Volume Shadow Copy, and ext3 too.
wrapper around the rm command to prevent accidental deletions
Name:
Anonymous2012-08-29 1:54
>>79 The entire internet and the web and the whole entire infrastructure that depends on Unix is just a really big toy.
The internet depends on PHP and JavaScript too. Unix is a toy because it was designed for single-user non-networked operation, like MS-DOS. Unix ("castrated Multics") was to Multics what MS-DOS ("Quick and Dirty Operating System") was to various DEC OSes. Both are cut down toy versions of OSes that were big for their time but small by today's standards. The whole idea behind Unix and MS-DOS security is that nobody would try to attack the machine on purpose. Microsoft realized that DOS was obsolete and created Windows NT.
Name:
Anonymous2012-08-29 2:06
>>96
Here are more different things: Trash/Recycle Bin and FAT Undelete. What they all have in common are (1) ways to recover a file that has accidentally been deleted and (2) they aren't part of Unix. Ext3 journaling is more like the USN Journal which are not ways to recover files that have accidentally been deleted.
Name:
Anonymous2012-08-29 2:21
>>98
Networking was a bolt-on thing for Multics too. Not that Multics is the best example of this anyway - the canonical ARPANET OS was Tenex.
Windows NT is hobbled forever by its Win32 userspace. The kernel is the only part of NT that's even remotely defensible. As of the 2.6 Linux kernel, there isn't even a whole lot left that's special about *that*.
>>93
If I was running a server with anything valuable, which I do, I would have backups, because guess what: HARDWARE FAILS
Name:
Anonymous2012-08-29 2:58
>>100
Saying that Unix and MS-DOS were non-networked helps explain that they were "secure" because "nobody would try to attack the machine on purpose" when they were created. They were toy OSes, not designed for the real world of the internet and/or multiple users on one machine simultaneously. In the modern world where everything is connected to the internet and there are malware writers, Unix and MS-DOS are inadequate. ``Fixing'' a buffer overflow by writing a note in the man page doesn't work anymore. Networking was a bolt-on thing for Multics too.
Of course, an OS created before the internet would not be expected to have ARPANET networking until it was actually invented.
>>98 The whole idea behind Unix and MS-DOS security is that nobody would try to attack the machine on purpose.
The whole idea behind Windows security is ``do you want to install this toolba...oh fuck it, of course you do, toolbars are fucking awesome !''
>>104-5
The Desktop Linux Retard Bins are actually superior to Windows and OSX, because Window and OSX change the icon when something is in them, almost like a notification. Instinctually, I empty the bin whenever it's ``full'' just to keep it ``clean''. Whereas on my Linux machine, there is no trash icon; I have to open Nautilus, ctrl+l, "trash:///" to even see it, so just about every file I've ever deleted on the desktop is still in there, because it isn't always in the corner of my eye begging me to delete it.
As it so happens, I've never had to recover anything from it. Ever. Because I don't delete file I want to keep. So complicated!
The sad thing about the Handbook is that it still stings, just a little bit. (Whatever happened to all those theoretically wonderful, persistent, capabilities-based systems? I'd like to have one of those ``toys'' to play with sometime...)
Name:
Anonymous2012-08-29 4:01
>>109 Whatever happened to all those theoretically wonderful, persistent, capabilities-based systems?
Stallman and other GNU Jews killed them.
Name:
Anonymous2012-08-29 4:04
>>104 OS X has a trashcan for retards.
"rm -rf *" still goes around trash can and undelete still doesnt work.
>>109
Capabilities never made it out of academia because people are too invested in Unix and Windows. ;-; GNU was exploring how to get capabilities in Hurd. Unfortunately, multi server capability design is very difficult to do properly - just like the rest of the Hurd architecture.
If you ran a server that contained anything valuable,
you would have backups of anything valuable, and wouldn't be mucking about as root all the time anyway.
>>108 Windows inherited much of the socket API from BSD Unix.
That explains the ``prefixes'' found on the Winsock structure field names. typedef struct in_addr {
union {
struct {
u_char s_b1,s_b2,s_b3,s_b4;
} S_un_b;
struct {
u_short s_w1,s_w2;
} S_un_w;
u_long S_addr;
} S_un;
} IN_ADDR, *PIN_ADDR, FAR *LPIN_ADDR;
typedef struct addrinfo {
int ai_flags;
int ai_family;
int ai_socktype;
int ai_protocol;
size_t ai_addrlen;
char *ai_canonname;
struct sockaddr *ai_addr;
struct addrinfo *ai_next;
} ADDRINFOA, *PADDRINFOA;
`
>geniuses create operation system
>idiot does something stupid with operation system
>therefore, the geniuses are idiots and the idiot is a genius
OP logic.
>>125
That's the browser that stops it, not the operating system. Unix doesn't do anything to prevent idiots like >>1 from writing a browser that does install extensions at the system level, other than allowing such idiots to rm -rf * before they get a chance to do anything really harmful.
>>129
And? Microsoft's browser has no security, because it takes after its OS. And most Windows exploits are done through the browser, so their browser is the weakest link. Therefore, Windows has no fucking security.
Oh, unless you count the Norton nag screen begging you for money.
>>130
It's not a quote, idiot, it's code. Can't you see it's wrapped in a code tag?
Faggot.
Name:
Anonymous2012-08-29 14:48
>>33
The other day I put gas in my Linux car so I can drive it. Then I began driving and the OOG killer blew it up. Whoever invented OOG killers was an idiot. The car should just stop where it was so you can refill the tank or call a tow truck when it runs out of gas.
# Supposing you are using a good Linux distro, now you can stop
# shooting yourself in the foot all of the time.
alias mv='/bin/mv -i'
alias rm='/bin/rm -I'
>>140
Except that these aliases serve a definite purpose: they prevent users from accidentally deleting files. Even experienced users will eventually accidentally use the commands erroneously, and these aliases will protect them from that.
Name:
Anonymous2012-08-29 17:48
>>145
The best alias is a trashcan or an undo feature in the filesystem. Alas Unix has no undo.
Imagine a text editor without an undo feature. That would be the Linux version of Notepad (with a retarded name like GNotepad or KNotepad).
>>150
Unix has safety features. rm has safety features (-i, -I). You can override rm so that it moves files to ~/.trash (if you're that much of a retard). All the more reason >>1 is a retard, because he could have easily implemented the functionality he desires and didn't. How many more safety features do you need?
Name:
Anonymous2012-08-29 18:44
>>151 You can override rm so that it moves files to ~/.trash
When your leg is already sawed off. You can as well pray to God, so he will give you a new one.
Buffer overflows, tedious and slow development, memory leaks, no type safety, #define, no generics, everything is undefined, shitty and exploitable standard libs...I could go on.
>>153
Yeah man, should make those operating systems in Java.
Name:
Anonymous2012-08-29 21:02
>>157
C makes you reinvent the wheel for every single program. Most programmers aren't wheel experts so they make shitty hash tables and reference counting that are slower than professional hashes and GC. Null-terminated strings in C are the cause of the majority of buffer overflows and other bugs. Most of C's descendents (C++, C#, D and Java) don't use them as their main string type because of all the exploits. You might be better off writing an OS in Java even with the JIT because you could spend your time adding features and optimizing the JIT and GC instead of fixing string bugs and buffer overflows.
>>158 You might be better off writing an OS in Java even with the JIT because you could spend your time adding features and optimizing the JIT and GC instead of fixing string bugs and buffer overflows.
What on earth would the JVM run on top of if you're writing the kernel in Java?
Name:
Anonymous2012-08-30 1:48
Thread is full butthurted shiteating Linux-faggots. As if it is they who lost all their files. Although I'm sure they did already a few times.
>>124
Windows programmers must mutilate what they do not understand.
>>164
Dalvik and Hotspot the Hotspot JVM are both C programs that run as userspace processes. Java bytecode assumes that the JVM is doing its own thread and memory management, so you will always need a host system that implements them.
I'm sure you could spend a lot of time and write a tiny assembly kernel that can do nothing but run Java bytecode on your target hardware, but what would be the point? C is more portable than assembly, and just as fast.
>>165
I think the context was about writing the OS in Java because of
the JIT compilation and "because you could spend your time adding features and optimizing the JIT and GC instead of fixing string bugs and buffer overflows". For me, I don't have any motivation to write such an OS for those reasons. If I was interested in OS work, I'd much prefer to contribute to something like HaikuOS, ReactOS, Hurd, Coyotos or InfernoOS.
>>158 Null-terminated strings in C are the cause of the majority of buffer overflows and other bugs.
It's programmers who have no idea how to do basic arithmetic that's the real cause.
You shouldn't be programming if asking yourself "how long can this string be" is beyond your mental capability.
(A secondary effect of this is poor API documentation that isn't specific enough when it comes to lengths.)
>>158 Null-terminated strings in C are the cause of the majority of buffer overflows and other bugs.
Use a better string library, like bstring. http://bstring.sourceforge.net/
And I don't want a text editor to take >10MB of memory, like most MOBILE CLOUD ENABLED SOCIAL SHARING Android text editors.
GC is shit.
Name:
Anonymous2012-08-30 10:19
GNOME is lean, not wasting code on error handling trash!
Why check the return value of malloc? Just let it crash! http://article.gmane.org/gmane.comp.audio.jackit/19998 Also, almost all sensible libraries enforce an aborting malloc()
anyway. For example, glib/gtk works exclusively with aborting
malloc, and that's the same for quite a few libraries. That means the
entirety of your GNOME desktop, or even many system daemons such as
HAL or DeviceKit-disks abort on OOM, and if you think it is worth
handling OOM in your user software one might wonder what the point is
if the underlying services dont't.
Name:
Anonymous2012-08-30 14:33
>>170
GNOME wastes code in every other place though. However I don't think anything will abort on OOM under linux. To my knowledge, linux will launch the OOM killer if more memory is requested than is available, and kill the lowest priority process.
Name:
Anonymous2012-08-30 14:37
>>168
Is checking the return value of malloc (>>170) beyond developers' mental capability as well? Would you use a sound library that could terminate your process at any time with no warning?
Name:
Anonymous2012-08-30 15:47
>>171
Why not killing the offending app? Linux is retarded.
Name:
Anonymous2012-08-30 16:11
>>173
Because it's hat-on-ass idiotic to assume the process that happens to be requesting use of memory is also the one that can most safely/usefully be killed. Since it's by definition active, it's likely to be the worst choice, even.
(The OOM killer doesn't naïvely kill the process with the lowest priority either; it's more complicated. This is what it tries to do:
/*
* oom_badness - calculate a numeric value for how bad this task has been
* @p: task struct of which task we should calculate
* @p: current uptime in seconds
*
* The formula used is relatively simple and documented inline in the
* function. The main rationale is that we want to select a good task
* to kill when we run out of memory.
*
* Good in this context means that:
* 1) we lose the minimum amount of work done
* 2) we recover a large amount of memory
* 3) we don't kill anything innocent of eating tons of memory
* 4) we want to kill the minimum amount of processes (one)
* 5) we try to kill the process the user expects us to kill, this
* algorithm has been meticulously tuned to meet the principle
* of least surprise ... (be careful when you change it)
*/
>>173
Let's say you've used all but a few hundred k of memory. Now let's say systemd decides to allocate a little memory. Linux kills systemd, you get the standard "attempted to kill init" deal.
Name:
Anonymous2012-08-30 18:37
>>175
System should kill offending code. I.e. which one allocated the most.
>>176
Stupid and naïve. The process that allocated the most memory also likely contains most of the user's unsaved work.
There's a reason the OOM killer works the way it does. The implementers spent more than half a second thinking about what makes sense.
Name:
Anonymous2012-08-30 18:48
>>177
User should use a better process to keep his unsaved work or buy additional RAM.
Imagine a text editor without an undo feature. That would be the Linux version of Notepad (with a retarded name like GNotepad or KNotepad)
I have no need for a bloated GUI for editing plain text files. That's why ed exists.
?
sage because troll thread
Name:
Anonymous2012-08-30 20:24
>>176
No, malloc should fail when there's no memory left.
Just say ``NO" to broken GC in the kernel.
Name:
Anonymous2012-08-31 3:54
>>180
This. The kernel should not be a GC and system daemons should always be able to function without additional memory.