Forgot your password?

Comment: Re:None of them. (Score 1) 288

by ThePhilips (#47564039) Attached to: Which Is Better, Adblock Or Adblock Plus?

How about the fact that Chrome has an up to date implementation of Flash that continues to get security updates... And don't tell me I don't need flash, you'll be just moving the goalposts with your argument.

That is somewhat ironic, since I find video quality of Google's own YouTube to be the worst with the Google's own Chrome. Either way - HTML5 or Flash - in Chrome sometimes HD videos are shown highly pixelated. Works fine - everyt time - in Fx and IE.

Anyway, FlashBlock (which can also be simulated with the AdBlock), side-steps most of the Flash-related security problems.

Comment: Lots of people... (Score 1) 524

Lots of people want physical home/back buttons.

Lots of people also want non-glossy screen.

Lots of people *need* resistive touch-screen, because capacitive ones can't be used in gloves.

But all that doesn't mean that it is going to happen. Production/etc moved to Asia - distance between customer and manufacturer is as great as it ever was.

I personally do not expect thing to get better.

Comment: Re:I, in turn, disagree (Score 1) 241

by ThePhilips (#47488895) Attached to: Math, Programming, and Language Learning

Man, I haven't even mentioned the numerical computing. It is an exception, because that's where programming serves the math, not the other way around.

In numerical computing, ironically, there is very little overlap between the math methods used in the development and math methods used for the goal of the development. Programs there often look more like a math formula. Developers simply skip the "computer science" as a whole and use the computers (with help of specialized libraries) as almost pure calculators.

As an exception, it is simply obscures the subject of the discussion.

The talk here is about what precisely from the math is used in general software development. (IOW, math serves the programming.) My personal experience, having majored in the applied math 15 years ago, is that by studying math one learns the methods to approach the real world problems. "Learns" is a weak word. The methods are implanted, grafted (or even brandmarked) onto the brain. Normal person's brain go into freeze when faced with thousands pages of specification. Person with math background, already switched into "divide and conquer" mode, and probably has already dismissed the >90% of it as trivial, incremental and derivative. (Some people learn it one their own. But studying math is definitely a nice shortcut to get there faster and earlier.) But the math in itself, either discrete/algebra or analysis or numerical, is very very rarely needed.

Comment: Re:I disagree (Score 1) 241

by ThePhilips (#47488019) Attached to: Math, Programming, and Language Learning

discrete math


Then it is fine. I would expect programmers to struggle with classical math geared toward physics. That's perfectly logical: it is easier for people who come from physics because they understand the applications. And vice versa: physicists have huge problems with discrete math, where you can't round or generalize everything to hell.

Otherwise, it was repeated many times before. The math in itself is not as useful as studying math is. Math doesn't relate to software development directly - but mathematical methods and approaches translate often one to one.

Studying math is fitness for the brains and method to the fitness.

P.S. But it doesn't mean that people who are good at math are good at programming too. Theoretical math != applied math. I have seen profs who could invent a new proof for theorem on a whim (forgotten notes), but struggled to implement something as trivial as a quick sort.

Comment: Re:Next Big Thing! (Score 1) 176

I've used emacs for that (editing 'uneditable' things in the buffer and then re-executing). See my post above - handy link here

OK. You completely miss the point.

Emacs' shell wrapper is just that: shell wrapper. Typing anywhere but at command prompt makes no sense. Command goes at the bottom. Output after it. Command at the bottom. Output. Rinse and repeat. You can't have (a) commands/outputs out of order, (b) non-shell commands or (c) re-execute in-place part of output as command.

Probably you simply never met with such problems so it is hard for you to even realize where from I'm (and apparently authors of xiki are) coming.

Comment: Re:Next Big Thing! (Score 1) 176

I dunno about the rest, but for filesystem browsing you can use vim :e on a directory which vim will then let you navigate

Well, you really have to try it first to understand the difference.

Browsing a directory in VIM - ':E' - shows you the content of directory in a buffer. What xiki demo shows is more of ^X^F (because you edit the path right in the editor window, with the rest of your text) but allowing you to actually dynamically run ^X^F on different parts of the dir/file name, changing content of the window accordingly. IOW, while ':E' is a dedicated browser, xiki does something like ^X^F to allow to edit/browse/etc inline, right in the middle of the text file, at any time when you need it.

And that's where the "innovation" comes. The tools to do all the things exist. But they all have different (and typically graphical) user interfaces. Xiki/etc try to combine the tools by putting them into an text editor, and making their output interactive and/or ready to be fed to the another tool. Because despite all the chrome, the basic nature of the content of the editor's window doesn't change: it is plain text. Commands are just text lines. Output are just text lines. It all becomes alive when special macro is run, which looks at the current line and tries to decide what to do with it.

Another way to look at it, and the way I often use my VIM hack, is that the same text file serves dual purpose: it is at the same time the script and the output of the script. The script and its output are interleaved. (That for example allows a very nice minor perk: rerun any command, flip between undo/redo and see the differences between then and now.)

Comment: Re:Next Big Thing! (Score 1) 176

Can you describe something that Xiki can do that cannot be done with `:r!`?

I can't. Because I do not use Xiki. I use something much simpler coded in VIM.

But the paradigm as I use it, in VIM terms: the command and the output are kept in the same editor window. You can apply exiting VIM functions to both - commands and output. You can save and load both at the same time - since in the essence it is an ordinary text file. With a special ':g//' I can rerun all the statements in file at once. Or I can selectively rerun only particular ones by the mask. I can ':w' and it is all made persistent. (My small creation was born first as a text file to keep the shell pipelines I use often. But with a VIM macro I have integrated also the output of the commands into the file. And then I given names to the commands. And then I allowed in pipes to refer to other pipes by the given names. After adding folding, it is still mostly looks like a text file with shell pipelines. Replaced bunch of terminals I used to keep open to run small monitoring/diagnostic commands. And a calculator, which I use most often (iow, a text file full of formulas, which I can copy/paste/modify and recalculate).)

Xiki, being a cross of Ruby and a text editor, apparently does more: it recognizes and presents as interactive not only the shell commands, but also the file system hierarchy, the Ruby code, the SQL statements, the CSS, the HTML, and probably more.

Comment: Re:Next Big Thing! (Score 1) 176

For those already on VIM: [...]

I already do something similar in VIM, and xiki is far from been the same as ":r!". You probably should watch the first screencast.

The xiki thing is basically a Ruby shell, with built-in free-form text editor. But primarily it is a wrapper around the Ruby. Thus it limits its appeal to mostly Ruby users and developers.

The concept is definitely interesting. It basically brings back to CLI some capabilities that many have given up to GUIs. Adding something like this to an editor like VIM is definitely possible, but not trivial, since VIM's support for scripting and scripted buffers is very limited.

OTOH the xiki reminds me of what Emacs does to the shell prompt. Unfortunately, Emacs' integration with the shell ends with the repetition of commands and copy-paste from the buffer. Xiki goes a step further.

Comment: Re:Yes, Perl is indeed dead and rotting (Score 0) 283

by ThePhilips (#47302113) Attached to: Perl Is Undead

More telling is how utterly fast Perl is compared to the other languages.

The test is ridiculous.

In any (Perl) program more complicated that helloworld (and in Perl terms that could be already pretty sophisticated piece of code) most of the time would be spent on calling functions.

All the test accomplishes, is testing how well Perl itself is implemented. And that we know already. (This test is basically biased against Java, or in fact, any language with immutable strings. Java just tops it off with slow IO.)

I use Perl still when doing scripting tasks. I love Perl, always have. I don't, however, necessarily think it's the right choice for building a medium to large web-based application any more. Sure the performance is there [...]

That's the problem: performance of Perl5 with any kind of largish framework would be pretty miserable because Perl's interpretation model is not designed to handle it.

Literally all interpreters decades ago went with p-code interpreters - and only Perl5 is still stuck with the traditional interpretation by (slightly optimized) syntax tree.

In my personal tests I have seen a clear dependency between performance and the size of optree: larger the optree, slower the code.

With any kind of sizable framework, the optree would be enormous. While bytecode allows for more aggressive optimization (inlining or IPO or profile based optimizations; after all, bytecode is just data), optree is very hard to modify (it is structured and inter- and intra-linked).

Comment: Re:time to die... (Score 1) 204

by ThePhilips (#47293261) Attached to: X Window System Turns 30 Years Old

No. Remote display is used everyday. Network transparency is not.

Remote display is used only if you are locked into the Windows. And comes with bunch of little problems, of which stuck keys and broken clipboard (until server restart) are though most annoying, the least. Recently admins where I work had to reboot PDC simply because a disconnected remote session got stuck and server didn't allow new sessions because RDP supports only one session.

But that's on Windows, where people have no choice. On *NIX, there is no good reason to choose RDP/VNC over X+ssh. But if you wish, you can RDP/VNC too.

Funny enough remote display is a feature possible on Wayland too.

Do you even know what you are talking about? Wayland's official statement is that network support is out of scope. Because Wayland is an interface to *local* graphical subsystem.

As network support goes, Wayland has only recently gained support for the X protocol (aka X Server can use Wayland as a display driver).

Comment: IO pattern (Score 3, Insightful) 164

by ThePhilips (#47251097) Attached to: Endurance Experiment Writes One Petabyte To Six Consumer SSDs

That's a heck of a lot of data, and certainly more than most folks will write in the lifetimes of their drives.

Continued write cycling [...]

That's just ridiculous. Since when the reliability is measured in how many petabytes can be written?

Spinning disks can be forced into inefficient patterns, speeding up the wear on mechanics.

SSDs can be easily forced to do a whole erase/write cycle just by writing single bytes into the wrong sector.

There is no need to waste bus bandwidth with a petabyte of data.

The problem was never the amount of the information.

The problem was always the IO pattern which might accelerate the wear of the the media.

Comment: Re:Anybody please! (Score 1) 270

by ThePhilips (#47210775) Attached to: Firefox 30 Available, Firebug 2.0 Released

You linked to the list of bugs *fixed* in 3.6

Vast majority of the later bugs were actually caused by the major internal redesigns starting with the version 4: new JS engine (which changed 3 or 4 times) and reworked layout engine. And IIRC there was even one UI security bug, where web-site could trick new FireFox into displaying green verified label for a compromised site.

I'm not saying that 3.6 is perfectly secure. But with AdBlock, FlashBlock and NoScript, it is probably more secure than the recent FireFox out of box. The add-ons cut off the major exploit vectors at the root.

We have a equal opportunity Calculus class -- it's fully integrated.