Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

I typed "rm /tmp/ *"

Name: Anonymous 2012-08-28 5:32

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: Anonymous 2012-08-30 1:06

>>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: Anonymous 2012-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.

Name: Anonymous 2012-08-30 3:15

>>162
Freedom-hating Microsoft faggot detected.

Name: Anonymous 2012-08-30 4:52

>>161
You could extend the JVM to be kernel or have some sort of VM on top of the kernel like how the Davlik VM works.

Name: Anonymous 2012-08-30 6:43

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

Name: Anonymous 2012-08-30 6:44

>>163
compile a kernel, tuxtard.

Name: Anonymous 2012-08-30 7:47

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

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-08-30 8:13

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

Name: Anonymous 2012-08-30 8:56

>>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: Anonymous 2012-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: Anonymous 2012-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: Anonymous 2012-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: Anonymous 2012-08-30 15:47

>>171
Why not killing the offending app? Linux is retarded.

Name: Anonymous 2012-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)
 */

For details, http://lxr.linux.no/linux+v3.5.3/mm/oom_kill.c)

Name: Anonymous 2012-08-30 18:17

>>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: Anonymous 2012-08-30 18:37

>>175
System should kill offending code. I.e. which one allocated the most.

Name: Anonymous 2012-08-30 18:42

>>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: Anonymous 2012-08-30 18:48

>>177
User should use a better process to keep his unsaved work or buy additional RAM.

Name: Anonymous 2012-08-30 18:59

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: Anonymous 2012-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: Anonymous 2012-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.

Name: Anonymous 2012-08-31 10:46

䌡芅閙㕅遒㘅㦑夕襧陓癣♓如锡焥ࡴ阷睹錕䕰㘗酵萖ᖆ䜀吐蚗‧鄸㡐恒☲円襡㐶耲蝠蒐靐鑦䥔᠇ᦕ摁瘈煑蜄劃䊒葩處偰瑷䈹䈩⒖獆㖑᎕顥蚀禗錕䈁奲剣ठ፣省㌙⍱蠶⠦ば㝈㌦蠵╔镢┥膁ΐᝲ硵䌁琲聰陆喕艁Ґᚐ噠煂㝹ࡓ✧禔⑘ᤄʀ䝇熅愅酥ᕐ茗䄙䝗⌄嘐䠢и硂爦᜹嘳ဤㅉ✔儤䍇錄㒖❑Έ⁰䖗⒁ሳ傇怂♴㉲銖饸獸ㄖ陣锘㆐㢐ᜉ匢䀠螗蠷ԧ饔ጨ癸㤃☐➑䠲〘兖舸琦⠀霓鈈耢ڈ恐ॖ‥Ƅ‡䥅ᑶ鐦〢螗螈鍨椀䥨栆䑈㑡瑡䢉չ㄄牨馈蕈癒᝵䉸⥄㕰㌒㎁摅ࠖ儂逘䆅恴ᖃƓ啡䕴戔ゔ儉㞂睢覒⤂枔₃†晵͕Ш噣產怦堦鍣㞀ᅘᅅ㌇嘰掐葙䝨㌖䒇ᄇ᠅ᘅ愓ɀ袓⌢捗兆吴سƀព桃愱ޖ瀖剗舳襓ᑳ㠸阁鉄萃睉蚐ᡉ噦睥xʁ⤣鈕шᙣ兤摉ᕹ硈塀霣咕̣膇敖㡸捁萑鐳⊅䐶處ⅆᘂł耓䥩ㄥ⠢䀙靱牴暑ॴ⤉嚀

Name: Anonymous 2012-08-31 10:57

疆腨〈杈጑б͈蕲㉇䚉楘əƇ䐨桵Α圄畕⍧ɒ᥃࠸㐥䐕䁸挶镕ঐ内ᑕչፇ醀㔰啠䜳≶∑䔀靇共ș嘠㉗䒄艅ॠȄ䦙䘩’頕鑩ɔ㤇❅吔∙䞂冁鑗̴䕕塷垘㈇ℤጓՈ螕䤖䕀䅑褵䠹∓ނ劒䁦⑉朙ڐ䜤ሄ⦘煹дᚉ㙇锹儠砦梅阘≣㙸ᔇ䐓ᙹ䅹す愇✆᜹灉喂桤颖ፙᘵش䅔ࡦℶ蘐ᆑ愃ᑷ覘䄦䠔熂梓㌦慳ら㚙䥖鉧̓ᡤ≡垂℀䁷⡈蕖〡ሄɴ⥁࢔ᄱ靦Ф萵㔡ሥ露圆ᤄ枖䘴㎇ㆁᤉҙ᎗䅷㘨┙⅀ځ⥃䌥顨杄甶阤࡙ᅤぇ褱Ԑ膘㝴㤡ᢖ❨锲蔶率硘䊘ғ整酣㢘၂褩斄慡碑醀ɠ㝂夠ᒘɈㅂ䉧煲䢐鎓蜅颙千饖選ᖔ玅挧š脂皀怷褔圵杨б冃萲搃嘅合摣㞕㐘⦓ʃ愘ℒ䎇⡰鉃䥑ဠ掐ㆄ酕餷腗ふԀ脵␴㌁䠉桢摣榐䂉琴饸䝱悙蔂慳㚙㐠鉖䕱䑹栄腶䠄ᔈ【镶閄憀䔂㤴敩ㅖ坲ႃ敳ቤ虈㤰焄茵Đࡘ䚁楨आ䀖镰卖⤆ᎁ㦗礖鐰朘᎗牱蕈
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -