You can still use Compact Flash cards with the A300 by buying an external slot that connects to a port on the back of the device. Also, the "port" on the bottom is proprietary but it's also faster than serial. I haven't done any speed measurements but still - USB networking is quite swift, and the builtin (automatic) samba server is really cool.:-)
You can always buy it from Japan Direct. Someone I know mailed them and asked about the A300 and they said they can get it for him for $600. He's very seriously considering it.
Actually, the processor isn't even close to be able to decode Ogg using a the freely available floating point libraries. As a matter of fact, I think one test showed that decoding 50 seconds of audio took 500 seconds. I.e it's painfully slow using an FP codec.
Click on one of the presets. This brings up a country / city selector. First find you country, then find your city. Press ok. Then close the timezone window and select the new preset in the drop down list.
Sure, a bit overly complex perhaps bit it's certainly not hard. This is also mentioned in the documentation.
Just download the apps from Sharp's My Zaurus site (where they have the terminal and file manager). Even better, download the enhanced OPIE version from their feed (be careful with installing too much OPIE stuff though - might break things).
Being the owner of one of the C++ wrappers I can say that I'd appreciate help with it. Recently lack of time has stopped me from updating it for a while but I think using it is really rather nice. See the SDLmm website for more info.
- Neo
Re:What about OpenAL?
on
Last Word on Loki
·
· Score: 2, Informative
Now although it's true that the OpenAL website points to the Loki CVS, one should note that the website (which is hosted at Loki) hasn't been updated for at least a year. Also, unless someone saves it, it might very well go offline with the rest of the Loki websites on January 31st.
Your point being? My point is that even with dynamic content, the average pentium III server today could server at least 50 req/sec (counting very low). This is 4.3 million requests in a day. If you get 20 million requests in a day during 11 hrs (US east/west coast market hours) that is 500 req/sec. Now, that might be hard for one server if the data is dynamic, but definitely not a problem for static data. Also the numbers quoted were 20k to 100k and 500k to 1M. That is NOTHING, trust me.
Using the example 11hr, 1 million reqs is just 25/sec (on average). To be able to serve 20k requests in a day, you need (hold your hats) to be able to pump out a page in 4.3 seconds! WOW, that's fast!
The scale quoted in the Dell article (if that is in fact what it said) would have been a problem in the distant past with CERN running from inetd on a Sun 3/80. Maybe.
What surprises me is that no one seems to react to the number they are talking about - 20-100k? What kind of box are they selling? A 386? 100k is barely one request per second. Any modern box with _ANY_ webserver can handle 1 request per second. Even the webserver written in Postscript can do this!
It's easy easy for any PIII box (if you have the bandwidth) to pump out millions and millions of (static) requests per day.
20k? Ha! I have never in my life seen a box that was that slow. Even CERN httpd on a 496 could do many times that.
The bad point, NULL being printed as "0" in RXML, is fixed in Roxen now. It was a bug mainly because no one noticed it before. I generally never use NULL fields for example, since are (IMHO) bad from a database perspective.:)
Since there is no programming manual for Roxen 2.0, that's a problem. Roxen 1.3 had a limited, and certainly not extensive enough, programming documentation. As I said before, Roxen IS is working on this obvious problem. And yes, examples is where the manuals are lacking the most.
Comment on the regexps: Yes, regexp support in Pike is definitely lacking compared to Perl - regexps is where Perl is better than just about every other languages. There is no denying it. Better support for Pike is planned, but it's not as easy as using a preexisting package since Pike has "invisible" support for 16 and 32 bit strings in addition to 8 bit strings. That complicates things from a regexp engine point of view.
When it comes to Roxen / Pike stability - Real Networks use it A LOT, and I mean massive traffic. There are generally no problems with stability there, except when the occasional bug pops up (not only in Roxen/Pike but in clients accessing the servers).
Also, although in raw benchmarks Roxen does perform worse than for example Apache it often works better in real world apps. Also when you start comparing to PHP or Perl, Roxen/RXML/Pike doesn't look that bad anymore.
Check out the new tutorial. It does a great job teaching the basic, and more advanced, aspects of Pike. Prior to that tutorial, it didn't really have such a thing.
When it comes to Roxen 2.0, there is not yet a programming manual. It's being worked on however. And instead of spending 5 hrs searching you should have sent an email to the Roxen mailinglist and you'd received an answer within less than 1 hr I'm sure.
Pike, or LPC as it was used to be called, is based syntactically on LPC. However there is no shared code due to the license of LPC (couldn't be used commercially I believe). Before LPC, there was LPC4, which _was_ based on LPC. It was also written by Fredrik but was abandoned in favor of what became Pike.
Why do you say that? Generally a pike program is about a 10th of the size of the same program written in C. Some languages, for example PHP4 are almost mimicking C (most PHP4 modules are simply wrappers to C functions). Pike is higher level than C. It might help if you explain why you think its too low level.
C-like syntax. Not a very important point, but when it comes to learning the language it's much easier than say Perl if you come from a C/C++ background. It's basically a highly evolved LPC (of LPMUD fame).
A very powerful Image package. Can load tons of formats natively including Photoshop (psd) and Gimp (xcf). Used by Roxen to do all kinds of graphics generation on-the-fly.
Powerful datatypes - mappings, multisets, shared strings. Nothing unique, but Pike's are very scalable. Also string handling is rather powerful.
Integrated bignum support. Pike 7 can handle arbritrary size integers without any special effort from the programmers point of view.
Very good and easy to use socket handling. Not strange since the main app written in Pike is a webserver.
Good object orientation, easy-to-use abstracted database handling, very nice GTK bindings and lots of more things I have forgotten about etc.
Now to some drawbacks - we all know that everything isn't all good.
Shared strings, and datatypes in general, does have a memory overhead. Usually not noticable but if you deal with LOTS of short strings for example, you'll notice it. Nothing really unique to Pike though, but it's worth mentioning.
Not very wide spread usage and historically not very well documented. There are no Pike books, but there is a good tutorial now (check out http://docs.roxen.com).
Slower than C - can't be avoided. Slower and faster than Java (depending on what you do), sometimes slower than perl. Unfortunately I have forgotten the URL to the site that had benchmarks.
Less mature than some other languages. Syntax still changes, although backwards compatibility usually isn't major problem.
More things I'm sure. I just can't think of anything right now.
I wrote that message and yes, I placed an order right before (or maybe right after) the beta test was over. Many people got their copies weeks before I did (I finally received it last Friday last week).
Of course, what we don't know here is how many copies they initially had to send - we can't forget that they also sent the games to stores all over the place (ie their own stock wasn't the entire batch I assume).
I wonder why this is posted on a news site as well. The Lunar Embassy has been selling their properties for years. I myself got a deed about two years ago.
People wonder why you would want to buy it. Well, isn't it rather simple? It's a fun thing. Obviously I don't expect that I will ever be able to claim my property, but since when is spending $20, or whatever the current price is, for something cool a bad thing?
Well, the "redhat only" in this case obviously only applies to the binary modules and patch (since the RH kernel is patched per default they might not apply cleanly to other drivers). However often when a company says "only for XXX" it means that they used that distribution to test their program and don't _guarantee_ that it works on another distribution. For example Acrobat Reader was for "Caldera Linux" (don't know if it still is) even though it worked on other Linux distributions.
Basically, even though Linux is Linux, distributions differ. It is not always easy to develop generic Linux stuff that works on them all.
I've had my share or problems with those drivers, as has many others. However this is with new cards, ie 3c905C etc. The benefit of 3Com releasing drivers are of course that new cards will be supported faster. Their driver supports the 3C980 series for example - something Don's doesn't. They do acknowledge Don however and also have no intention, as far as I can tell, to support older cards like 3c509.
So glibc 2.1 and kernel 2.2 isn't a major upgrade? I would say that it is. Might not be all THAT much difference from a user point of view I guess. Also 6.0 includes KDE which is nice.
Well, from a small test I just did, it doesn't seem to be the case. I made a program that forked 10 times, and then opened files in each child until it failed. I easily opened more than 1024 files totally.
Slashdot Mirror
You can still use Compact Flash cards with the A300 by buying an external slot that connects to a port on the back of the device. Also, the "port" on the bottom is proprietary but it's also faster than serial. I haven't done any speed measurements but still - USB networking is quite swift, and the builtin (automatic) samba server is really cool. :-)
You can always buy it from Japan Direct. Someone I know mailed them and asked about the A300 and they said they can get it for him for $600. He's very seriously considering it.
Actually, the processor isn't even close to be able to decode Ogg using a the freely available floating point libraries. As a matter of fact, I think one test showed that decoding 50 seconds of audio took 500 seconds. I.e it's painfully slow using an FP codec.
Uh. How about this then:
Click on one of the presets. This brings up a country / city selector. First find you country, then find your city. Press ok. Then close the timezone window and select the new preset in the drop down list.
Sure, a bit overly complex perhaps bit it's certainly not hard. This is also mentioned in the documentation.
Just download the apps from Sharp's My Zaurus site (where they have the terminal and file manager). Even better, download the enhanced OPIE version from their feed (be careful with installing too much OPIE stuff though - might break things).
Being the owner of one of the C++ wrappers I can say that I'd appreciate help with it. Recently lack of time has stopped me from updating it for a while but I think using it is really rather nice. See the SDLmm website for more info.
- Neo
Now although it's true that the OpenAL website points to the Loki CVS, one should note that the website (which is hosted at Loki) hasn't been updated for at least a year. Also, unless someone saves it, it might very well go offline with the rest of the Loki websites on January 31st.
- Neo
There's a mirror of the SP stuff at ftp://david.hedbor.org/wolf/. Download and be happy (just finished the last SP mirroring).
Your point being? My point is that even with dynamic content, the average pentium III server today could server at least 50 req/sec (counting very low). This is 4.3 million requests in a day. If you get 20 million requests in a day during 11 hrs (US east/west coast market hours) that is 500 req/sec. Now, that might be hard for one server if the data is dynamic, but definitely not a problem for static data. Also the numbers quoted were 20k to 100k and 500k to 1M. That is NOTHING, trust me.
Using the example 11hr, 1 million reqs is just 25/sec (on average). To be able to serve 20k requests in a day, you need (hold your hats) to be able to pump out a page in 4.3 seconds! WOW, that's fast!
The scale quoted in the Dell article (if that is in fact what it said) would have been a problem in the distant past with CERN running from inetd on a Sun 3/80. Maybe.
It's easy easy for any PIII box (if you have the bandwidth) to pump out millions and millions of (static) requests per day.
20k? Ha! I have never in my life seen a box that was that slow. Even CERN httpd on a 496 could do many times that.
Roxen Platform, which uses CVS as the backend storage, is worth mentioning. That is a full-fledged web-based content management system.
The bad point, NULL being printed as "0" in RXML, is fixed in Roxen now. It was a bug mainly because no one noticed it before. I generally never use NULL fields for example, since are (IMHO) bad from a database perspective. :)
Since there is no programming manual for Roxen 2.0, that's a problem. Roxen 1.3 had a limited, and certainly not extensive enough, programming documentation. As I said before, Roxen IS is working on this obvious problem. And yes, examples is where the manuals are lacking the most.
Comment on the regexps: Yes, regexp support in Pike is definitely lacking compared to Perl - regexps is where Perl is better than just about every other languages. There is no denying it. Better support for Pike is planned, but it's not as easy as using a preexisting package since Pike has "invisible" support for 16 and 32 bit strings in addition to 8 bit strings. That complicates things from a regexp engine point of view.
When it comes to Roxen / Pike stability - Real Networks use it A LOT, and I mean massive traffic. There are generally no problems with stability there, except when the occasional bug pops up (not only in Roxen/Pike but in clients accessing the servers).
Also, although in raw benchmarks Roxen does perform worse than for example Apache it often works better in real world apps. Also when you start comparing to PHP or Perl, Roxen/RXML/Pike doesn't look that bad anymore.
When it comes to Roxen 2.0, there is not yet a programming manual. It's being worked on however. And instead of spending 5 hrs searching you should have sent an email to the Roxen mailinglist and you'd received an answer within less than 1 hr I'm sure.
FYI, Roxen 2.0 / Pike 7 has embedded support for PHP4 and Java. There is also a working Perl interface in beta (possibly pre-beta) state for 2.1/7.1.
Pike, or LPC as it was used to be called, is based syntactically on LPC. However there is no shared code due to the license of LPC (couldn't be used commercially I believe). Before LPC, there was LPC4, which _was_ based on LPC. It was also written by Fredrik but was abandoned in favor of what became Pike.
Hope that clarifies that some.
Why do you say that? Generally a pike program is about a 10th of the size of the same program written in C. Some languages, for example PHP4 are almost mimicking C (most PHP4 modules are simply wrappers to C functions). Pike is higher level than C. It might help if you explain why you think its too low level.
Now to some drawbacks - we all know that everything isn't all good.
I hope this is helpful.
I wrote that message and yes, I placed an order right before (or maybe right after) the beta test was over. Many people got their copies weeks before I did (I finally received it last Friday last week).
Of course, what we don't know here is how many copies they initially had to send - we can't forget that they also sent the games to stores all over the place (ie their own stock wasn't the entire batch I assume).
I wonder why this is posted on a news site as well. The Lunar Embassy has been selling their properties for years. I myself got a deed about two years ago.
People wonder why you would want to buy it. Well, isn't it rather simple? It's a fun thing. Obviously I don't expect that I will ever be able to claim my property, but since when is spending $20, or whatever the current price is, for something cool a bad thing?
Basically, even though Linux is Linux, distributions differ. It is not always easy to develop generic Linux stuff that works on them all.
I've had my share or problems with those drivers, as has many others. However this is with new cards, ie 3c905C etc. The benefit of 3Com releasing drivers are of course that new cards will be supported faster. Their driver supports the 3C980 series for example - something Don's doesn't. They do acknowledge Don however and also have no intention, as far as I can tell, to support older cards like 3c509.
So glibc 2.1 and kernel 2.2 isn't a major upgrade? I would say that it is. Might not be all THAT much difference from a user point of view I guess. Also 6.0 includes KDE which is nice.
/ Haven't upgraded yet.
Well, from a small test I just did, it doesn't seem to be the case. I made a program that forked 10 times, and then opened files in each child until it failed. I easily opened more than 1024 files totally.