Worse : Chrome (especially V8) is only designed to work on ARM and i386 (32 bits) architectures. Yes, no AMD64 support, and don't even think of other architectures yet.
However, there is a lot of manpower behind the project and the developpers are very skilled. So this is not hopeless.
It's available, but it's experimental for a reason. It's absolutely not realiable for production yet. So it's not an option yet, it's just food for freebsd trolls.
Ahaha this reminds me a novel that Douglas Adams wrote to MacUser in September 1996. It's available in the book published after his death. The Novel is called "Les petits bitoniaux" in French, I don't know what the original title is, but it's worth a read.
You probably never coded on it. HP calculators were hackable. Almost no one coded on them using the built-in language or using system calls (way too slow), everyone used assembly language and it was great (I miss the P register) and there was no sandbox, except rules to follow in order allow GX/SX compatibility.
It was well documented and originally undocumented tricks like interrupts were quickly documented through the internet, minitel and bbs.
The hardware itself was also hackable and hacked. A lot of people designed their own memory cards, changed the IR leds, overclocked the CPU, etc.
Re:Establishing de facto (open source) standard ?
on
ECMAScript 4.0 Is Dead
·
· Score: 1
HP calculators have always been hackable. The 48 S/SX/G/GX calculators had a large and active scene. I spent countless hours coding on it. The Saturn processor was very nice to code on.
Last week's surveys by the DNSSEC developers ("SecSpider") have found a grand total of 99 signed dot-com names out of the 70 million dot-com names on the Internet.
Am I the only person amazed by this? We've had fifteen years of forgeries, fifteen years of concentrated work on DNSSEC, and we can't even get simple cryptographic signatures deployed. What an embarrassment for cryptography!
Hmmm. This reminds me that some web-page updates are overdue; it's time for me to announce the results of the attacks that the entire Internet will be panicking about in 2015.:-)
When I wrote that web page several years ago, I focused on deployment difficulties (which are obviously a huge issue) and delegating security to poorly managed central Internet servers (which is a big issue for high-security sites). But there are other reasons, maybe more important reasons long term, to be dissatisfied with DNSSEC, motivating the development of DNSSEC2 and DNSSEC3:
* RFC 4033, Section 4: "DNSSEC provides no protection against denial
of service attacks." In fact, DNSSEC makes denial of service even
easier than it was before.
The basic problem is that DNSSEC signs _records_ but provides no
protection for _packets_. After several packets a DNSSEC cache can
see that it doesn't have the expected signatures and that there
must have been forgeries, but the cache simply fails at that point;
it doesn't have any way to find the right data.
With DNSSEC2, every response packet has an immediately and
efficiently verifiable high-security cryptographic signature.
Forged packets are simply discarded.
* RFC 4033, Section 4: "DNSSEC is not designed to provide
confidentiality." DNSSEC doesn't even try to encrypt packets.
In fact, DNSSEC makes private DNS data _much_ easier for attackers
to see than before, because it exposes a huge amount of information
through "NSEC," and creates interoperability failures if NSEC is
disabled. The latest "NSEC3" adds even more complications but does
essentially nothing to repair the privacy leaks; NSEC3 might be
successful at its marketing goal of stopping European privacy
regulators but it will almost never be successful at the security
goal of stopping attackers.
With DNSSEC3, every request and response packet has high-security
encryption and authentication. Both DNSSEC2 and DNSSEC3 completely
avoid the "NSEC" privacy leaks.
* Although the DNSSEC protocol allows some conservative cryptographic
options that won't be broken in the near future, what DNSSEC users
are actually being told to deploy---to partially compensate for
serious speed problems in DNSSEC---is something that big companies
and botnet operators can _already_ break, namely 1024-bit RSA.
We're still years away from a _public_ announcement of a successful
1024-bit RSA factorization, but I think that telling people to
---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
DNS still vulnerable, Bernstein says.
CHICAGO, Thursday 7 August 2008 - Do you bank over the Internet? If so, beware: recent Internet patches don't stop determined attackers.
Network administrators have been rushing to deploy DNS source-port randomization patches in response to an attack announced by security researcher Dan Kaminsky last month. But the inventor of source-port randomization said today that new security solutions are needed to protect the Internet infrastructure.
"Anyone who knows what he's doing can easily steal your email and insert fake web pages into your browser, even after you've patched," said cryptographer Daniel J. Bernstein, a professor in the Center for Research and Instruction in Technologies for Electronic Security (RITES) at the University of Illinois at Chicago.
Bernstein's DJBDNS software introduced source-port randomization in 1999 and is now estimated to have tens of millions of users. Bernstein released the DJBDNS copyright at the end of last year.
Kaminsky said at the Black Hat conference yesterday that 120,000,000 Internet users were now protected by patches using Bernstein's randomization idea. But Bernstein criticized this idea, saying that it was "at best a speed bump for blind attackers" and "an extremely poor substitute for proper cryptographic protection."
DNSSEC, a cryptographic version of DNS, has been in development since 1993 but is still not operational. Bernstein said that DNSSEC offers "a surprisingly low level of security" while causing severe problems for DNS reliability and performance.
"We need to stop wasting time on breakable patches," Bernstein said. He called for development of DNSSEC alternatives that quickly and securely reject every forged DNS packet.
Apple: ok, FSF, you are right. Here's what we are going to do. We will ask every customer to switch to GNU/Hurd. But of course YOU will be in charge of the support. Hey, come back! What's wrong?
Slashdot Mirror
Worse : Chrome (especially V8) is only designed to work on ARM and i386 (32 bits) architectures. Yes, no AMD64 support, and don't even think of other architectures yet.
However, there is a lot of manpower behind the project and the developpers are very skilled. So this is not hopeless.
Please mod parent up.
Here : http://support.apple.com/kb/TS1502
I want support for multiples architectures.
IE is amd64 and i386 only.
Chrome is i386 and ARM only (not even amd64).
Mozilla is the only portable one.
It's available, but it's experimental for a reason. It's absolutely not realiable for production yet.
So it's not an option yet, it's just food for freebsd trolls.
No, it has no reason to break dynamic dns services like redirectme.net
Chuck Norris doesn't need any power adapter. Chuck *is* the power.
Ahaha this reminds me a novel that Douglas Adams wrote to MacUser in September 1996. It's available in the book published after his death. The Novel is called "Les petits bitoniaux" in French, I don't know what the original title is, but it's worth a read.
I second this.
I just tried with VMware Fusion with 3D acceleration enabled and it works.
PHPMyAdmin, OSCommerce, CodeIgniter... yep. Just quick and dirty hacks. Come on, lay off the generalizations.
PHP doesn't make crappy code, coders do. The same could be said (and has been said) about Perl, but it doesn't make it true.
OSCommerce... have you ever looked at the OSCommerce code?
Probably one of the most horrible code I've ever seen.
You're correct. Some of them aren't quick at all!
But they are as security flawed as quick ones.
There worse : Flash on *BSD.
FreeBSD only has an obsolete Flash 7 (and still as unstable as nitroglycerine, try it with KDE4 Konqueror, it does nothing but eat 100% cpu).
OpenBSD can only run Flash through a browser running Linux emulation, ie. Opera and nothing else.
Not sure about DragonFly and NetBSD, but it's probably the same.
You probably never coded on it. HP calculators were hackable. Almost no one coded on them using the built-in language or using system calls (way too slow), everyone used assembly language and it was great (I miss the P register) and there was no sandbox, except rules to follow in order allow GX/SX compatibility.
It was well documented and originally undocumented tricks like interrupts were quickly documented through the internet, minitel and bbs.
The hardware itself was also hackable and hacked. A lot of people designed their own memory cards, changed the IR leds, overclocked the CPU, etc.
Errrr uhmmm, ever heard of Java?
Have you ever heard about Haxe ?
I'd love to see Haxe ( http://www.haxe.org/ ) supersede Ecmascript.
HP calculators have always been hackable. The 48 S/SX/G/GX calculators had a large and active scene. I spent countless hours coding on it. The Saturn processor was very nice to code on.
Still I don't like PHP OO. After working with Ruby, I really miss mixin in PHP. Having to create new classes to add things is lousy.
It was posted on the djbdns list : http://marc.info/?l=djbdns&m=121832806123954&w=2
Here's what DJB said about this:
Last week's surveys by the DNSSEC developers ("SecSpider") have found a
grand total of 99 signed dot-com names out of the 70 million dot-com
names on the Internet.
Am I the only person amazed by this? We've had fifteen years of
forgeries, fifteen years of concentrated work on DNSSEC, and we can't
even get simple cryptographic signatures deployed. What an embarrassment
for cryptography!
Jos Backus writes:
http://cr.yp.to/djbdns/forgery.html states:
"My top priority for djbdns is to support nym-based security."
Hmmm. This reminds me that some web-page updates are overdue; it's time :-)
for me to announce the results of the attacks that the entire Internet
will be panicking about in 2015.
When I wrote that web page several years ago, I focused on deployment
difficulties (which are obviously a huge issue) and delegating security
to poorly managed central Internet servers (which is a big issue for
high-security sites). But there are other reasons, maybe more important
reasons long term, to be dissatisfied with DNSSEC, motivating the
development of DNSSEC2 and DNSSEC3:
* RFC 4033, Section 4: "DNSSEC provides no protection against denial
of service attacks." In fact, DNSSEC makes denial of service even
easier than it was before.
The basic problem is that DNSSEC signs _records_ but provides no
protection for _packets_. After several packets a DNSSEC cache can
see that it doesn't have the expected signatures and that there
must have been forgeries, but the cache simply fails at that point;
it doesn't have any way to find the right data.
With DNSSEC2, every response packet has an immediately and
efficiently verifiable high-security cryptographic signature.
Forged packets are simply discarded.
* RFC 4033, Section 4: "DNSSEC is not designed to provide
confidentiality." DNSSEC doesn't even try to encrypt packets.
In fact, DNSSEC makes private DNS data _much_ easier for attackers
to see than before, because it exposes a huge amount of information
through "NSEC," and creates interoperability failures if NSEC is
disabled. The latest "NSEC3" adds even more complications but does
essentially nothing to repair the privacy leaks; NSEC3 might be
successful at its marketing goal of stopping European privacy
regulators but it will almost never be successful at the security
goal of stopping attackers.
With DNSSEC3, every request and response packet has high-security
encryption and authentication. Both DNSSEC2 and DNSSEC3 completely
avoid the "NSEC" privacy leaks.
* Although the DNSSEC protocol allows some conservative cryptographic
options that won't be broken in the near future, what DNSSEC users
are actually being told to deploy---to partially compensate for
serious speed problems in DNSSEC---is something that big companies
and botnet operators can _already_ break, namely 1024-bit RSA.
We're still years away from a _public_ announcement of a successful
1024-bit RSA factorization, but I think that telling people to
DJB made a press release about this:
---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
DNS still vulnerable, Bernstein says.
CHICAGO, Thursday 7 August 2008 - Do you bank over the Internet? If so, beware: recent Internet patches don't stop determined attackers.
Network administrators have been rushing to deploy DNS source-port randomization patches in response to an attack announced by security researcher Dan Kaminsky last month. But the inventor of source-port randomization said today that new security solutions are needed to protect the Internet infrastructure.
"Anyone who knows what he's doing can easily steal your email and insert fake web pages into your browser, even after you've patched," said cryptographer Daniel J. Bernstein, a professor in the Center for Research and Instruction in Technologies for Electronic Security (RITES) at the University of Illinois at Chicago.
Bernstein's DJBDNS software introduced source-port randomization in 1999 and is now estimated to have tens of millions of users. Bernstein released the DJBDNS copyright at the end of last year.
Kaminsky said at the Black Hat conference yesterday that 120,000,000 Internet users were now protected by patches using Bernstein's randomization idea. But Bernstein criticized this idea, saying that it was "at best a speed bump for blind attackers" and "an extremely poor substitute for proper cryptographic protection."
DNSSEC, a cryptographic version of DNS, has been in development since 1993 but is still not operational. Bernstein said that DNSSEC offers "a surprisingly low level of security" while causing severe problems for DNS reliability and performance.
"We need to stop wasting time on breakable patches," Bernstein said. He called for development of DNSSEC alternatives that quickly and securely reject every forged DNS packet.
Apple: ok, FSF, you are right. Here's what we are going to do.
We will ask every customer to switch to GNU/Hurd.
But of course YOU will be in charge of the support.
Hey, come back! What's wrong?
Regardless of the vendor, DSDT tables for Windows are always the most tested path.
This is why the OpenBSD ACPI code disguises as Windows.
Add some correct SEO and accessibility support to Flex and you got everything we need.
Really.
We're just trying to reinvent what Flash can do for a while.
I used to do that with ease and great success with OpenBSD.
Using PF for load balancing and relayd to check link status and to automatically change PF rules when needed.
It worked great, never had any single failure with it. It was on a Soekris Net4801.
With OpenBSD 4.3, I think you can even do it without PF, just with routing.
As a different way to advocate and to celebrate Firefox 3, the french community of beauty technicians has set a challenge up.
It is open to anyone. You just need to feature the Firefox logo with nail art, tattoos, body painting, make up, hair design, hand-made jewels...
More about the Firefox beauty tech challenge : http://forum.manucure.info/firefox-day/en/