NO competent developer could identify the 'bottlenecks' in 600,000 lines of code in 15 days.
Got it now ?
I don't think you have ever participated in such a big project. Let's not even talk about managing it or single-handedly refactoring it. You have simply pulled that number out of your ASS.
Users of CDNs are encouraged to use
"Official Client-end CDN Software" to make access more convenient.
last time I've tried you couldn't query their bloody registry
with a simple whois client: you had to go through
a website with cookies, captcha and click-wrap agreement, or use a windows-only
binary. They're probably advertising the latter.
They're looking for "single frame" (about 10-20ms
long) expressions which appear on your face when you think you're
getting away with something. They've been used by the secret
service for years, and are amazingly accurate; they can detect
lies with 99% accuracy.
you're probably trying to be funny, but, sadly,
there are people ready to believe such outrageous shit.
were at odds with controlling access
to the main Utu repository, and Kevin accidentally proved Zed to
be right, when he (Kevin) accidentally wiped the configure file
for the whole project
Then what ? Everybody's doing mistakes,
especially with those braindead scm's. Why didn't he
just reverted the change that deleted that file ? Or use the backups if their scm was busted ?
Anyways, the whole story looks factually dubious.
At one point he's claiming that another guy was assuming all months having 30 days, and
this was just creating code with 'security' problems.
Also, languages are not by themselves slow, the virtual machines or interpreters are, so saying a language is slow is nonsensical.
Maybe in theory. For instance, there is only one implementation of Perl, there's no formal specification of
the Perl language (the language is defined by its standard implementation), and there's absolute 0% hope of
someone being ever able to do another bug-a-bug compatible interpreter. The same applies to Ruby, I think.
Then, most dynamic languages are forcing the implementors to keep type information at run-time, to do garbage
collecting, etc. All that comes at a price. It's simply impossible to get it as fast as a static language like
C or Fortran, even if you were to design special hardware for it (like Lisp machines).
Yes, dams prevent flooding by permanently (and irremediably) submerging whole swaths of land
with everything was there since centuries (villages, forests, fields, etc).
How 'green' is to destroy people's homes and lives and force them to leave AGAINST their will ?
Re:Not really a replacement
on
Hacking VIM
·
· Score: 1
'nvi' (which is the default on *BSD) is not the
'good old vi'.
If fact, nvi just like vim, has its own share
of 'improvements' and annoying incompatibilities.
(the most irritating of all being the fact that
it requires a cursor addressing terminal even if
run in 'ex' mode).
And unlike vim, nvi it isn't doing multibyte character
sets, which, unlike syntax highlighting and other
useless crap, is a real feature I can't do without.
Re:As a linux neophyte...
on
Hacking VIM
·
· Score: 1
:x is shorter and better than:wq.
the:wq's only use is for lamers to make ':wq' jokes,
write it in their email signatures, or wearing geek
teeshirts with ':wq' on it.
Those chess programs are beating humans by brute-force techniques, not
by AI techniques. The hardware has become immensely powerful and very
cheap, so it has become feasible to just 'break' the chess game, with giving up any AI pretensions.
Unfortunately, AI as of expert systems and self-learning programs has failed miserably.
Chess has the advantage that it has a relatively small set of
possible game combinations, and there's no doubt it would
become soon possible to completely 'solve' chess, just as
checkers.
Take the 'go' game. Even a 5 year old can beat (very easily)
the best go computer player. That's because (by pure
accident, I don't think they considered this possibility
when they invented it;-)) the huge number of
game combinations and the need of involved shape recognition techniques
make even thinking about the use of brute force absurd. So the
program has to rely on cheap tricks just to give the impression it does a bit more than just checking the moves for correctness, and make for some entertaining pass-time.
This gives an idea of how much AI has 'evolved' since 1950.
It's just you who don't know how to use the tools,
and stupidely ASSUME that people who are using
vi or emacs are 'manually searching and replacing'
(which is hilariously incorrect). YOU are probably doing that, and find it easier to do it with click-click and dialog boxes.
Well, I could draw you with pencil and paper the
whole structure of any program I've worked on.
The simple idea that the program you're working on
is a kind of make where you need smart tools to 'guide'
you means you're better finding another job: you're fucking with (and modifying!) things you don't understand.
IDE tools are just like GPS-interactive maps for
taxi drivers - they're only useful if the people themselves
are off-the-boat novices or hopelessly incompetent.
Actually Perl meets the 'natural language' criteria
of some dillettante who had struggled unsuccessfully to learn a
foreign language with a manual and grammar: no rule without at least 3 exceptions, and a lot
of misleading and unused logical paths.
The weirdness of the syntax has no technical motivation; it's
not like is reflecting some internal structures or following
some coherent principles; it's a bunch of ad-hoc
decisions based on the fact that somebody wasn't
liking too many parantheses, or has just fallen
suddenly in love with how nice a particular construct was
looking in some other language.
When I was first learning perl, I couldn't make sense
of why ex.
push/^\s*#/ ? @c : @d, $_ wasn't working. I've taken the
source and looked through it: perl wasn't keeping any track of the
type of the return value of an operator, but was
STILL enforcing some dumb type safety with a shallow
kludge that was looking only at the direct arguments for its
built-in functions, in a macro-toy-language way.
Mod parent up. <p> As long as I didn't give away some of my rights with a public license (GPL or BSD) or doing everything as a work for hire (for an employer), I retain absolutely all the rights to my creation, and nobody can legally use it in any way, or distribute it further without my permission. <p> There's no need to stick any copyright notice + list of rights & obigations or other shit. If I do stick one is to let people freely use it under some conditions, not to limit its use.
It's still compressed with gzip, not with bzip2. It was never compressed with bzip2. It's not called vmlinux.gz because it's not a proper gzip file - it's more complicated than that (vmlinuz include a boot sector, a gzip decompresser and then the compressed image of the kernel itself, everything packed like hell)
There's a modern PL/I compiler (kednos) that works on VMS.
I've played with it on vms/vax (on simh), but it probably works
on VMS on alpha and Itanium, too.
What is funny is how small and fast is when
compared to gcc, given all the stories about
PL/I being a 'big' language, that needs a compiler
100 times more complex than a C one.
Most serious people ignore the memory management routines supplied by libc - because they're crap. This includes your favorite open-source projects. If your application is malloc-bound, you/cannot/ afford to rely on the provided malloc/realloc, unless you want your app to be 20 times slower and use 5 times more resources because of memory fragmentation.
My 78000 lines Perl program takes 15 seconds to create a thread
Because the parent has no clue, and didn't bother to check the
perl ithreads implementation, or try it with anything else than
hello-world one-liners:)
The time to fork a new thread is proportional with how many
objects (strings, variables, etc) exists in the interpreter,
since it has to COPY them all.
To have some fun, let a threading perl load your 78000 script,
then dump a core file
(ex. 'ulimit -c unlimited' than 'dump' in the script), and run a
Slashdot Mirror
I use the '%' key in vi ;-)
$ find "${PATH} -type f -print0 | xargs -0 grep "${PATTERN}"
NO competent developer could identify the 'bottlenecks' in 600,000 lines of code in 15 days.
Got it now ?
I don't think you have ever participated in such a big project. Let's not even talk about managing it or single-handedly refactoring it. You have simply pulled that number out of your ASS.
Changed all tabs into 8 spaces ? Camelcased class names ?
I could do all that in half-an-hour with sed and awk, no need to register for evaluation.
Anyways, the whole story looks factually dubious.
At one point he's claiming that another guy was assuming all months having 30 days, and this was just creating code with 'security' problems.
Maybe in theory. For instance, there is only one implementation of Perl, there's no formal specification of the Perl language (the language is defined by its standard implementation), and there's absolute 0% hope of someone being ever able to do another bug-a-bug compatible interpreter. The same applies to Ruby, I think.
Then, most dynamic languages are forcing the implementors to keep type information at run-time, to do garbage collecting, etc. All that comes at a price. It's simply impossible to get it as fast as a static language like C or Fortran, even if you were to design special hardware for it (like Lisp machines).
How 'green' is to destroy people's homes and lives and force them to leave AGAINST their will ?
If fact, nvi just like vim, has its own share of 'improvements' and annoying incompatibilities.
(the most irritating of all being the fact that it requires a cursor addressing terminal even if run in 'ex' mode).
And unlike vim, nvi it isn't doing multibyte character sets, which, unlike syntax highlighting and other useless crap, is a real feature I can't do without.
the :wq's only use is for lamers to make ':wq' jokes,
write it in their email signatures, or wearing geek
teeshirts with ':wq' on it.
Give a man a fish, and he can eat for a day.
Teach a man to fish, and he will be caught poaching, and beaten to death by the rangers.
Unfortunately, AI as of expert systems and self-learning programs has failed miserably.
Chess has the advantage that it has a relatively small set of possible game combinations, and there's no doubt it would become soon possible to completely 'solve' chess, just as checkers.
Take the 'go' game. Even a 5 year old can beat (very easily) the best go computer player. That's because (by pure accident, I don't think they considered this possibility when they invented it ;-)) the huge number of
game combinations and the need of involved shape recognition techniques
make even thinking about the use of brute force absurd. So the
program has to rely on cheap tricks just to give the impression it does a bit more than just checking the moves for correctness, and make for some entertaining pass-time.
This gives an idea of how much AI has 'evolved' since 1950.
Well, I could draw you with pencil and paper the whole structure of any program I've worked on.
The simple idea that the program you're working on is a kind of make where you need smart tools to 'guide' you means you're better finding another job: you're fucking with (and modifying!) things you don't understand.
IDE tools are just like GPS-interactive maps for taxi drivers - they're only useful if the people themselves are off-the-boat novices or hopelessly incompetent.
The weirdness of the syntax has no technical motivation; it's not like is reflecting some internal structures or following some coherent principles; it's a bunch of ad-hoc decisions based on the fact that somebody wasn't liking too many parantheses, or has just fallen suddenly in love with how nice a particular construct was looking in some other language.
When I was first learning perl, I couldn't make sense of why ex. push /^\s*#/ ? @c : @d, $_ wasn't working. I've taken the
source and looked through it: perl wasn't keeping any track of the
type of the return value of an operator, but was
STILL enforcing some dumb type safety with a shallow
kludge that was looking only at the direct arguments for its
built-in functions, in a macro-toy-language way.
Mod parent up.
<p>
As long as I didn't give away some of my rights
with a public license (GPL or BSD) or doing everything as
a work for hire (for an employer), I retain absolutely
all the rights to my creation, and nobody can legally
use it in any way, or distribute it further without my permission.
<p>
There's no need to stick any copyright notice + list of rights & obigations or
other shit. If I do stick one is to let people freely use
it under some conditions, not to limit its use.
It's still compressed with gzip, not with bzip2.
It was never compressed with bzip2.
It's not called vmlinux.gz because it's not a
proper gzip file - it's more complicated than
that (vmlinuz include a boot sector, a gzip
decompresser and then the compressed image of the
kernel itself, everything packed like hell)
don't forget the beer !
There's a modern PL/I compiler (kednos) that works on VMS.
I've played with it on vms/vax (on simh), but it probably works on VMS on alpha and Itanium, too.
What is funny is how small and fast is when compared to gcc, given all the stories about PL/I being a 'big' language, that needs a compiler 100 times more complex than a C one.
what is all that idiocy with pressing 'back' in internet
explorer and wordpad ?
is there any link where to actually DOWNLOAD an archive or
a tape/disk image ?
The next iteration of OpenMoko will have WiFi with
an Atheros chipset, they say.
The problem with OpenMoko is its repulsive shape.
Was the case design made by the girlfriend/wife of the
project leader ? Why should it be THAT ugly ?
I read the thing at:
http://wiki.forum.nokia.com/index.php/TSS000431_-_Requesting_extended_capabilities_set_for_Developer_Certificates
I found that racket absolutely disgusting.
Are people so desperately needing to develop for symbian ?
Most serious people ignore the memory management /cannot/
routines supplied by libc - because they're crap.
This includes your favorite open-source projects.
If your application is malloc-bound, you
afford to rely on the provided malloc/realloc,
unless you want your app to be 20 times slower
and use 5 times more resources because of memory
fragmentation.
Because the parent has no clue, and didn't bother to check the perl ithreads implementation, or try it with anything else than hello-world one-liners :)
The time to fork a new thread is proportional with how many objects (strings, variables, etc) exists in the interpreter, since it has to COPY them all.
To have some fun, let a threading perl load your 78000 script, then dump a core file (ex. 'ulimit -c unlimited' than 'dump' in the script), and run a
strings | grep | wc -l on it.