Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:why? (Score 1) 677

3. Some compilers don't even try to optimize a function containing a goto.

I call bullshit on this.

As to your other points, don't forget that C doesn't have labeled loops, like java or perl.

So no, "goto" is NOT easy to avoid, if you have to break out of an inner loop. The alternative (set a variable then test it on each iteration of each outer loop) is ugly, messy, inefficient and is obfuscating the program logic.

Most people that pretend to avoid gotos are cheating by "refactoring" the resource freeing blocks into separate functions and then using multiple return paths, which is just as anti-Dijkstra as going full gotos everywhere.

Comment: Re:Come on already (Score 1) 64

by Anonymuous Coward (#48938123) Attached to: D-Link Routers Vulnerable To DNS Hijacking
There are a lot of routers with an USB that are supported by OpenWRT, TL-MR3420 is not that interesting. I've got my TL-WDR3600 (gigabit, 2 usb ports, 5GHz support) for less than $40. Unfortunately no hardware NAT support on OpenWRT, so I'm limited to ~300Mbs on wan.

If you have a USB-port, you can stick whatever device supported by linux in-there, not just "GSM" modems. The limitations are mostly because of the crappy stock firmware. And many recent HSPA and LTE modems are themselves linux-based routers, and appear like a CDC ethernet interface, so they just work, auto-magically.

Comment: Re:Just keep it away from Gentoo and I'm good (Score 1) 551

by Anonymuous Coward (#48836977) Attached to: Systemd's Lennart Poettering: 'We Do Listen To Users'

*zsh is also bloated

No, it's not.

It's much smaller and faster than bash.

As to your scripting in ash, it's the worst of two worlds: its lack of features will criple your scripts, without making them compatible with either the posix or the traditional bourne shell. Solaris' /bin/sh should be a much better target if you want a vanilla shell.

And please stop repeating silly gnu-dissing that makes you feel part of a higher circle: the actual enhancement that 'caused' the shellshock vulnerability (functions as part of environment) was actually copied from plan9's rc, ie the result of the same kind of brainless plan9 snobbery like yours.

Comment: Re:My opinion on the matter. (Score 2) 826

by Anonymuous Coward (#47751353) Attached to: Choose Your Side On the Linux Divide



ex/vi had ':x' (and ':x!') since its very beginning, which has the advantage of not 'touching' the file gratuitously when no changes were made.

There's also the 'ZZ' command while in visual mode.

Are you also using 'cat | grep'? This parrotting of 'geek creed' signs is really getting on my nerves -- better don't show up with your 'wq:' tee-shirt in my neighborhood ;-)

Comment: Re:Perl 6ers just can't get shit done. (Score 1) 283

by Anonymuous Coward (#47306105) Attached to: Perl Is Undead

except it's not true that all working interpreters are direct c interpreters. plan 9's rc implements a virtual machine (which it even bootstraps) and interprets the virtual machine.

How come? When was that true?

Looking through the source code of rc ( there is absolutely nothing of the sort.

It's a simple interpreter that creates some intermediate bytecode out of the syntax tree, and then execute it in a stack machine.

Very much like mawk or such.

You probably have vague recollections about limbo/inferno, go or other similar failures they've churned out since then.

Comment: Re:Python (Score 1) 466

Native code, for example, refers to code in its binary (processor-specific) form. No processor that I'm aware of knows how to run C code natively - it has to first be taken from its portable format and translated into native (assembly and then machine) code. It's not a matter of when or how that translation happens; processors simply don't speak C.

You still don't get it.

Running your Python code is not just a matter of 'translating', 'interpreting', whatever they say in tutorials. The problem is that your program needs /at runtime/ some bloated, slow VM written in C and it will still need it even if you compile your program into native code. It simply cannot work without it.

By comparison, if I compile C program for the attiny13a, I get some dozen or hundred bytes to put into its memory to run through them, and that's it.

And the situation wouldn't change no matter how many compiler passes I do, or what "abstraction level" I use, or whatever. It's still very much an assembler, even if I was producing machine code from flowcharts, koans or gestures.

Comment: Re:Python (Score 1) 466

Claiming that hardware can run C natively is quite a reach. Your definition of what it means to run a language natively is so broad that it encompasses a large number of programming languages (if not all of them).

It's not about the number of passes of the compiler or if a language is supposed to be portable or not, but about the "virtual machine" abstraction a language is assuming, and how far is that from what typical hardware has to offer.

To run any Lisp or Python program, no matter what interpreter/compiler you use, you need to implement garbage collection, reflection, run-time code evaluation, etc.

Those features are neither light-weight, trivial nor scope-limited, unlike software routines implementing integer multiplication/division (on alpha) or a floating point emulator (on most arms) -- that are needed for a full C implementation.

And if you strip your language of those complex features, you also lose the 10x productivity you like to claim, and you simply get a C without pointers.

Comment: Re:Python (Score 1) 466

Not only was Python /originally/ written in C, it /still/ is written in C.

And most hardware is able to run C natively -- C is just a glorified assembler. And ISAs which didn't map nicely to C, like pdp10, are long gone.

Anybody would love a system programming language other than C, less anchored in single-threaded '70 pdp11 concepts and idiosincrasies; but as long as there isn't any, stop pitching your slow bloated language-of-the-day, and pretending that with enough kool-aid and meditation, you can replace C with Java or Python.

Comment: Re:How is this a good idea? (Score 2) 249

by Anonymuous Coward (#47216957) Attached to: New Permission System Could Make Android Much Less Secure

Also, android has a linux kernel, which means iptables-based firewalling works

Not necessarily.

On my phone the kernel was built without iptables support.

I had to beg for the modified kernel sources, wait 3 months to get them, and then waste a lot of time to learn about the stupid idiosyncrasies of 'android is not gnu', just to get that standard linux feature working.

Comment: Re:I would think (Score 1) 379

by Anonymuous Coward (#46801015) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week
[snipped long litany of cliches and platitudes]

If I were a programmer

That's the problem: you're not.

and found that completely unacceptable, I could always choose not to work on such an important project critical to the security of so many.

That the old tired meme used to keep honest competent people out of critical jobs; but unlike generals and politicians, programmers able to work on OpenSSL don't grow up in trees, so you will have to make do with (almost) the same people and stuff your "incentives" and "reactions" up your ass.

Comment: Re:Oh, man, what a mess (Score 2) 151

I do have to wonder if the task was made easier given the purpose of the server. After all, I'd think it wouldn't get traffic at all except for those people responding to the challenge.

On the contrary, it may have made things harder.

Reading the private key relies on forcing malloc() to reuse some small block from the free block list with a lower address than the block containing the key, insteading of simply carving a new block out of free memory (with an address higher than the key).

That may be easier to do on a busy server, because you don't have to send millions of queries just to fragment its memory; you may just assume that malloc is already reusing freed blocks, and exploit the algorithm it uses to do that (eg by manipulating the length of payload to let it allocate some unusual size block for which some gap just before the key is the perfect fit).

Comment: Re:Let it die (Score 1) 510

I have met a lot of them, and while they are extremely friendly people, they are also staunchly conservative when it comes to things like cochlear implants and what they see as the erosion of Deaf culture.

Does a cochlear implant let one hear as "normal" people do, or at least as much as an 80-old with a hearing aid?

If the answer is "not quite", then they have all the reasons to be conservative.

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling