IIRC it has to do with DNS hosts that don't answer at all (or correctly) to IPV6 DNS requests. Some bad home routers also are said to be a possible cause
When IPv6 is enabled on the client machine, mozilla does a AAAA lookup first, and if there is none, does a lookup for the A record. Correct response for a name server if there is no AAAA record (but the domain exists) is to return NOERROR, with an empty reply. The BBC server returned NXDOMAIN (which was incorrect), and mozilla exhibited correct behaviour by assuming that the domain did not exist.
So apparantly people start an email client _on average_ within 12 minutes after an install and catch a virus? That is pretty rough, and IMHO unrealistic. I don't know what most people do, but I'm usually still install drivers, turning off teletubby mode etc.
Sounds like the vendors included a few old worms that snatch chronically unpatched systems, and gave it a spin to boost antivirus sales.
"The right tool " mantra works both ways. Both from the developer perspective and from user perspective.
The dependancies (install a few apps, and you have 100MB on various script languages, and extra modules) and speed are the trouble.
I'm talking about slow from the viewpoint of a recent Athlon64. Even if it gets twice as fast in the two next years, it is still annoyingly slow.
I have had the trouble to be forced to program in Perl, to fix some predecessors code. My conclusion was that while it was nice to get something under 1000 lines working quickly, IMHO the development speed went down for anything non-trivial, often to below even C speed. C, though a bit too spartan for my taste, is at least debuggable and predicatble.
Note that I'm not a C advocatists. I have other preferences. But they are not viable, partially because of the same problems as I don't deem the scripting languages viable: dependancies.
Another thing that might play for me is being *BSD user, doing a lot of source building (manual or ports). One get the builddepends as well as the rundepends.
I hate having to have install Perl, Ruby and Python (m4?) for all kinds of trivial stuff. (or have it in the base systems as more and more systems do).
First, these scripting languages are slow. People that don't agree, please compile X, and watch the font making in Perl. It eats more time than actually compiling X
Second, every stupid package uses another one, so you end up with a bunch of them.
Third, it requires more languages to learn to access the system. Moreover, the amount of languages that can interface to Perl modules is significantly lower than the amount that can interface to C (virtually all). This can also be seen in the article: the perl backend is unused, everybody works around in shellscript.
The first two could be solved by e.g. limiting the tools to a perl subset that is compilable to C, and not use too many modules.
The third is harder to solve. Best would be to code the package system in C, and have a C callable library. Or maybe using 2C kind of stuff.
I'm developer, and since the compiler compiles itself, it is its best testsuite. I typically use it when wired to the PC and then ssh into the PDA's Linux OS. (still the only usuable OS for my Zaurus)
A collegue also did turn his Zaurus into a useful wifi access point though at a convention. This was done ad hoc, and not prepared, which added enormously to the geek factor:_)
Why stuff it in your computer? It should be in your PDA!
Before the Palm I used my Zaurus for a while, but that gradually transformed to a development station, and the instability of the (non SHARP original) OpenZaurus firmware made it less doable for after a while.
So I bought an old M515 second hand. The thing's batteries last near forever, and the sync software (Palm Desktop), while simple gets the job done for easier PC data entry.
Actually that will be hard (and I say that as FPC developer).
The Delphi language - runtime system has a small set of extensions that are only half portable. (e.g. a full fledged Linux can do or emulate it), mainly to get the designtime system so flexible
While it is practically doable to implement this into any imperative languages, with languages that have strong standard adherence, it will be really hard to get this past the standard folk.
The threading-in-language is only threadvar. Not to different from most C++ compiler extensions.
Note that is roughly the same as gcc TLS, it is a normal compiler feature.
I think Delphi is an ideal language, except I really would like to have generics. The ways to construct complex somewhat typesafe datastructures from that is nice. ( I think more in an ADA way than a C++ way though).
>1) Way too verbose for my tastes syntax - my fingers hurt when I do Delphi:-|.
Then use the codetools more. (lazarus also has these)
> "Procedure" and "function" separation is also too obsolete.
> 2) Libraries/APIs need to be ported.
Only header files. FPC interfaces pretty damn well to C. Native string types can be even passed if read only (and writeable only needs a length update after write: setlength(x,strlen(x));)
> 3) Infrastructure (editors etc) is of course less developed than for C.
FPC has Lazarus as RAD, there is Delphi, C has ?
I think the whole C vs Pascal argument is bogus. C remained pretty much a systems language, with Delphi/FPC Pascal mainly moves into the Application area.
Slashdot Mirror
> Delphi is Windows only and owned by a company with a very questionable future (forget about Kylix). C# is > basically Windows only as well.
The Borland implementation of Delphi is, but others aren't:
http://lazarus.freepascal.org/
Other departments should depend on you, but that should not cost too much work.
This simply to get a certain form of "currency" to use in negotiations with other departments.
I think he meant Kalingagrad (Koenigsberg) with the Eastern Poland remark.
My first thought to.
_Molten_ sodium (Natrium) chloride even. Not something you want in cars either.
IIRC it has to do with DNS hosts that don't answer at all (or correctly) to IPV6 DNS requests. Some bad home routers also are said to be a possible cause
(From https://bugzilla.mozilla.org/show_bug.cgi?id=6879
When IPv6 is enabled on the client machine, mozilla does a AAAA lookup first,
and if there is none, does a lookup for the A record. Correct response for a
name server if there is no AAAA record (but the domain exists) is to return
NOERROR, with an empty reply. The BBC server returned NXDOMAIN (which was
incorrect), and mozilla exhibited correct behaviour by assuming that the domain
did not exist.
See also
https://bugzilla.mozilla.org/show_bug.cgi?id=2316
To be honest, it always has been hard to get an idea about the final builds performance from beta's.
Beta's always have been painfully slow, until right before release, and the first RTM warez versions showed up.
One of the things I'm expecting from Longhorn can't be seen in screenshots.
I'd expect a significant drop in UI latency due to the new minimal standards for video hardware, much like Panther. (OS X 10.3).
(for the ones that missed that, Geforce3+ or comparative ATI required. From that, it seems that programmable T&L is what they are after)
Anybody has any hands on info? Does LH feel faster than XP?
Why do they mumble over virusses then in the article?
See my remark over adding stats over wellknown old vulnerabilities (that have been patches 1.5 years+) triggered by worms to boost antivirus sales
So apparantly people start an email client _on average_ within 12 minutes after an install and catch a virus? That is pretty rough, and IMHO unrealistic. I don't know what most people do, but I'm usually still install drivers, turning off teletubby mode etc.
Sounds like the vendors included a few old worms that snatch chronically unpatched systems, and gave it a spin to boost antivirus sales.
Since that also contains a lot of vitamin D.
UV radiation stimulates vitamin D production yes, but for a reason, to repair cancer damage.
"The right tool " mantra works both ways. Both from the developer perspective and from user perspective.
The dependancies (install a few apps, and you have 100MB on various script languages, and extra modules) and speed are the trouble.
I'm talking about slow from the viewpoint of a recent Athlon64. Even if it gets twice as fast in the two next years, it is still annoyingly slow.
I have had the trouble to be forced to program in Perl, to fix some predecessors code. My conclusion was that while it was nice to get something under 1000 lines working quickly, IMHO the development speed went down for anything non-trivial, often to below even C speed. C, though a bit too spartan for my taste, is at least debuggable and predicatble.
Note that I'm not a C advocatists. I have other preferences. But they are not viable, partially because of the same problems as I don't deem the
scripting languages viable: dependancies.
Another thing that might play for me is being *BSD user, doing a lot of source building (manual or ports). One get the builddepends as well as the rundepends.
I hate having to have install Perl, Ruby and Python (m4?) for all kinds of trivial stuff. (or have it in the base systems as more and more systems do).
First, these scripting languages are slow. People that don't agree, please compile X, and watch the font making in Perl. It eats more time than actually compiling X
Second, every stupid package uses another one, so you end up with a bunch of them.
Third, it requires more languages to learn to access the system. Moreover, the amount of languages that can interface to Perl modules is significantly lower than the amount that can interface to C (virtually all). This can also be seen in the article: the perl backend is unused, everybody works around in shellscript.
The first two could be solved by e.g. limiting the tools to a perl subset that is compilable to C, and not use too many modules.
The third is harder to solve. Best would be to code the package system in C, and have a C callable library. Or maybe using 2C kind of stuff.
I'm developer, and since the compiler compiles itself, it is its best testsuite. I typically use it when wired to the PC and then ssh into the PDA's Linux OS. (still the only usuable OS for my Zaurus)
:_)
A collegue also did turn his Zaurus into a useful wifi access point though at a convention. This was done ad hoc, and not prepared, which added enormously to the geek factor
Don't know. I don't play with the Palm. The Zaurus is infinitely more fun to play with. (and runs openssh, and Free Pascal Compiler)
I would be surprised if GNU Chess wasn't ported.
However the Palm does its job better as a raw PDA than the Zaurus. Probably because it is older (m68k based), the batteries last longer
Why stuff it in your computer? It should be in your PDA!
Before the Palm I used my Zaurus for a while, but that gradually transformed to a development station, and the instability of the (non SHARP original) OpenZaurus firmware made it less doable for after a while.
So I bought an old M515 second hand. The thing's batteries last near forever, and the sync software (Palm Desktop), while simple gets the job done for easier PC data entry.
Not an improvement to shell out cash for, but still an improvement
Open Source is always about developer, not user headcount.
Half the Linux distro's have less developers than the avg BSD. Let's kill them off.
Pretty much everything that FPC uses data2inc for. Mostly to create structures with variable length string data in it.
Another example; see e.g. the macro's for sysctl constants in the FreeBSD headers.
There is a _reason_ why there are so many Star Wars references in the Evil Overlords list
http://www.eviloverlord.com/lists/overlord.html
Oeps, missed that correction. Sorry!
Actually that will be hard (and I say that as FPC developer).
The Delphi language - runtime system has a small set of extensions that are only half portable. (e.g. a full fledged Linux can do or emulate it), mainly to get the designtime system so flexible
While it is practically doable to implement this into any imperative languages, with languages that have strong standard adherence, it will be really hard to get this past the standard folk.
Maybe I should have said " can be handy for some kinds of structures".
A good example is e.g. a datastruct where strings are coded using their minimal length.
So string or string
FPC didn't have an IPO that could be abused to fund pissing contests
The threading-in-language is only threadvar. Not to different from most C++ compiler extensions.
Note that is roughly the same as gcc TLS, it is a normal compiler feature.
I think Delphi is an ideal language, except I really would like to have generics. The ways to construct complex somewhat typesafe datastructures from that is nice. ( I think more in an ADA way than a C++ way though).
Disadvantages:
:-|.
>1) Way too verbose for my tastes syntax - my fingers hurt when I do Delphi
Then use the codetools more. (lazarus also has these)
> "Procedure" and "function" separation is also too obsolete.
> 2) Libraries/APIs need to be ported.
Only header files. FPC interfaces pretty damn well to C. Native string types can be even passed if read only (and writeable only needs a length update after write: setlength(x,strlen(x));)
> 3) Infrastructure (editors etc) is of course less developed than for C.
FPC has Lazarus as RAD, there is Delphi, C has ?
I think the whole C vs Pascal argument is bogus. C remained pretty much a systems language, with Delphi/FPC Pascal mainly moves into the Application area.