To expand on that, in ISO-Latin in general and certainly ISO-Latin-1, and thus by extension Unicode (which maps to ISO-Latin-1 for code points in the range 0x00 to 0xff), the area 0x80 to 0x9f was on purpose not used for displayable glyphs in order not to cause interoperability problems with 7bit systems if an 8bit text was moved between systems and the 8bit was stripped off.
So unless you are using a non-Unicode, non-ISO-Latin encoding there are no printable characters in that range, and if you're using another character you will need to remap the characters before considering any of the rules in the XML spec anyway, since those rules refer to the unicode codepoints.
In which character set? Certainly not in Unicode, so if anyone used 0x85 as à in XML documents using any Unicode encoding they've messed up. à (latin letter a with grave) is 0xE0, and À (lating chapital letter a with grave) is 0xC0.
Unicode 3.2 define 0x85 as a newline character. This change just make XML follow the Unicode spec, which isn't unreasonable considering that the parser is expected to use Unicode internally (or to act as if it does).
The user is irellevant in measuring time spent by the browser and the X server in rendering the interface, or acting on user actions, and there is no logical reason why a non-native interface would have to be slower than a native one there, and that is the claim I responded to.
Whether the user interacts with it slower is a different issue, but an issue that refers to whether you've implemented a good look and feel, not whether or not the interface is native or not.
There is nothing stopping someone from implementing something that looks and feels like the native Windows interface from scratch - several people have done so: QT is one such implementation. There's also nothing stopping anyone from designing an interface that would be more intuitive to the average user than a "native" interface.
And for X there is no native interface, so the point is moot anyway. You may believe that the XUL based interface is a bad design, or is implemented badly, but that it's a "non-native" interface is completly irellevant.
But it all boils down to this: Some people automatically blame XUL for anything that's wrong with Mozilla's performance. It's perfectly possibly XUL has part of the blame, but making the claim just because it's a "non-native" interface without having bothered checking whether XUL is a factor is both meaningless and annoying.
With those memory amounts, it sounds to me like you're quoting the number of virtual pages allocated for the processes... Notice that that includes things like shared libraries that are used across processes, and also a lot of stuff that never will get paged into RAM unless you actually use it. So a lot of the size difference between Mozilla and Phoenix will simply be shared libraries that aren't mapped in, but that you'd never load in Mozilla either unless you actually use one of the features that have been stripped out.
I still like Phoenix, and it does save memory, but make sure you look at the resident set, not virtual pages allocated when you want to judge actual memory usage.
So, why don't you post a summary of the extensive profiling you apparently have done to be able to tell that the non-native interface is the issue?
There is no logical reason why a "non-native" interface would have to be slower than a native one. If you look closely, you'll notice that even on Windows lots of applications use "non-native" interfaces, it's just that most of them are made to look as close as possible to what you'd call the "native" interface.
True, the implementation might suck, but if you think it does, then post profiling data. Otherwise, leave the whining to people who do bother to profile it and find the real trouble spots.
Re:Self publishing could be a sign of bad quality
on
Reflecting Fires
·
· Score: 4, Informative
"Organizing" self-publishing these days means uploading the file to xlibris or a similar service, something which can be done with a few hours work.
But getting accepted by an agent is often just as hard as being published, as the agents don't want to waste their time with works they think will be rejected by publishers.
When it comes to it having to be bad quality not to be published, consider that many highly regarded works were rejected time and time again before a publisher took them on. It's not unusual for books to be rejected by 15-20 publishers before you find someone to publish your work. Most of them will take their time before they respond, if they ever do.
Quite a few people might give up well before that, even if what they've written might well have been a tremendous success if it had been published and marketed properly.
Publishers aren't omniscient. Beatrix Potter self published her childrens books because no publisher would take them on, Emily Bronte's Wuthering Heights was rejected multiple times,
Dune was rejected 13 times, M*A*S*H was rejected 21 times, just to take some examples.
And not everyone are in it for the money.
Of course you'll find lots of crap among self-published works, but you'll also find lots of works that are great but just too narrow to find a wide enough audience for a publisber to be interested, and you'll find the occasional work from someone who have given up on the publishers despite having an incredible work...
In most business calculations, your requirement is to be able to round with sufficient accuracy to meet demands from your auditors and the government. That typically means that between 2-5 decimals fixed point will be enough. Yes, you still have to deal with rounding, but usually because there are lots of business rules and laws that regulate how you deal with financial data: Inland Revenue in the UK, for instance recognize two ways of calculating aggregate VAT for an order consisting of multiple items, and one of them is specified as calculating the VAT for each item to three decimal points, sum them up and round to two, and explicitly states the rounding rule to use.
Doing that with integers is trivial: Keep sums to the tenth of a pence, sum them together, and write your own one line inland_revenue_round() function that rounds the way Inland Revenue requires it.
Same applies for what you're saying. Of course you need to care about rounding, but doing rounding of integer fixed point representations is trivial if you know the rounding rule you need to apply.
But you have to deal with rounding issues and precision with floating point as well, though lots of people don't realize that and screw up because the results are much closer to expected most of the time.
Most people that used fixed point deal with 2-3 decimal points for financial transactions, so precision is rarely an issue. Of course there are always some people with weird requirements. But in particular the guy I replied to brought of business/financial usage where a 32 or 64 bit integer would be more than enough for fixed point with 3 decimals.
Most of us wouldn't be any better at all. My math is rather rusty, though I used to be good at it at school. The reason my maths is rusty is because in the 7 years I've been doing commercial software development I have almost never needed any maths.
When I have, I've never needed anything beyond what I could find in a textbook or online in less than 5 minutes.
Heck, I've practically never even had any reason to use floating point math over that period of time.
Sure, there are lots of areas where you do need maths beyond what you can pick up from a book in 5 minutes, but there are far more where maths is irellevant.
Beyond basic algebra, maths is just another set of domain knowledge that you'll need to aquire to do particular types of software development, not something that is an inherent requirement in order to be a good coder.
The reason so little focus is given to what you call "decimal math", and most people would call "fixed point" is that there's a very simple way of doing it: You do everything with integers scaled sufficiently high up, and move the comma to the right the prerequisite number of steps to get the number of decimal points you want.
Oh, and there are lots of old fixed point code floating around. Looking for "fixed point" instead of "decimal math" might help you find what you want...
And exactly how would it be different to project on fog trapped between plexiglass and projecting on other types of screens?
It would stick out just as much as with any other projection technology - the problem with projection is being able to project a clear enough image with high light intensity without ending with a ridiculously deep screen. That problem is exactly the same whether you project on fog, a piece of cloth, or your ass...
No, I don't find it ironic, considering that all four of them use RPM. Now referring to Debian, that is ironic, considering that most distros use a different install system that it does.
Rendering models like Java2D, Display Postscript, Display PDF, the X Render model or SVG can all be made to make use of OpenGL with orthographic
rendering (z value affect sorting only, not scaling) , as they make heavy use of things like alpha compositing, rendering of polygons, various transformations, and even lighting and other filtering effects (at least SVG). I think you'll see 3D graphics cards being increasingly utilized for normal desktop applications too.
Have you tried Evolution? The only thing remaining I'd consider useful would be new posting and shared calendars/busy-free schedules. Apart from that it interoperates with Exchange very well, though only via IMAP/SMTP. If you want the calendar etc. as well, Ximian have a (proprietary) solution for that.
There are lots of applications that will benefit from this. But what I would like to see are faster disk storage systems, not faster memory... But then my main work over the last years have been huge mail systems (entirely disk IO bound) and extremely fault tolerant database distribution (.name TLD resolution system, also almost entirely disk IO bound).
I'd be very happy to find a storage solution that gave us transfer rates that would get us anywhere near utilizing the full CPU capacity even with entry level servers these days for non-computing intensive processes such as mail delivery, serving DNS queries or fault tolerant message queueing...
(and preferrably one that doesn't cost ten times more than any potential savings from reducing the number of servers...)
Actually all Amiga's back to the original A1000 can do that. The Amigas essentially had two memory buses: One for the CPU and all the auxilliary chips (referred to as "chipram" - this included the video chip, timers, audio, etc.) and one that was exclusively accessible by the CPU ("fastram")
Some models came only with chipram as default.
Running programs from "chipram" was slow, since the CPU was unable to access it and would have to wait whenever any of the other chips accessed it.
When you allocated memory, you could choose to request a specific type of memory (if you needed the memory to be accessible to the auxilliary chips, you'd request chip ram, if you needed the speed you'd request fastram) or
not care, in which case fast ram was allocated unless there was no big enough block of fastram available.
But the possibility that some of them are authentic believers means that it is meaningless to even talk about punishing anyone for it, as thinking that most people who put it down were pranksters does not prove that a specific person that put it down is a prankster.
Officials of the government passing any judgement about what is a legitimate religion is opening the door for decisions that will deprive people believing in "fringe" religions of rights, simply because most religions out there are considered ridiculous fiction by some group or other.
The question about religion IS essentially meaningless - asking people what they believe and then trying to judge whether or not they have been truthful is something that is incredibly easy
to manipulate.
Yeah, I suppose the cost of someone looking at the summary and saying "70.000 Jedi? Surely that must
be a joke. Group those 0.37% in with the 'other' category" would be horrendous when amortized over all the tax payers.
Who are you to say that those people don't really define themselves as Jedi? I can think of a large number of more ridiculous religions that have followers that take it really seriously (enough so to account for quite a few mass suicides, for instance).
Ultimately I doubt the census bureau will try to do anything, as it is next to impossible to prove anything about a religion - after all a religion is based on faith and beliefs, not proofs, and any attempt to push people on it might lead to uncomfortable decisions affecting "real" religions...
Actually, in Britain both are used, but calling 1.000.000.000 a billion is the most "modern"
usage. While millard is legal English, it's not
very common anymore. In French and Norwegian for instance, milliard is still commonly used for 1.000.000.000, though, and billion for 1.000.000.000.000
On the corporate side, I agree with you. On the home computing front, not so. The PC was the defacto standard in the business world years before it wrested control from in particular Commodore 64, Amiga and Atari ST in the home computer area.
The computing power and graphics capabilities delivered by the Amiga and Atari in particular went rings around the PC for a lower price for a long time.
I remember gloating over how slow and expensive my fathers 4.77MHz PC ran compared to my Amiga 500 that was a lot faster, had proper graphics and multitasking and cost less than a third even if you factored in a harddisk.
It was first after the PC dominated in business, and gaming capabilities of the PC started getting comparable to the home computers that the PC began doing serious inroads in the home market, and then the competition got important as it allowed faster price drops in the PC market than among the home computer manufacturers.
Actually, the rival IS a supplier. Or multiple. If you read the article, it's pretty clear that Telstra is looking at Linux because one or more of it's current large suppliers are pushing Linux.
Slashdot Mirror
So unless you are using a non-Unicode, non-ISO-Latin encoding there are no printable characters in that range, and if you're using another character you will need to remap the characters before considering any of the rules in the XML spec anyway, since those rules refer to the unicode codepoints.
In which character set? Certainly not in Unicode, so if anyone used 0x85 as à in XML documents using any Unicode encoding they've messed up. à (latin letter a with grave) is 0xE0, and À (lating chapital letter a with grave) is 0xC0.
Unicode 3.2 define 0x85 as a newline character. This change just make XML follow the Unicode spec, which isn't unreasonable considering that the parser is expected to use Unicode internally (or to act as if it does).
Whether the user interacts with it slower is a different issue, but an issue that refers to whether you've implemented a good look and feel, not whether or not the interface is native or not.
There is nothing stopping someone from implementing something that looks and feels like the native Windows interface from scratch - several people have done so: QT is one such implementation. There's also nothing stopping anyone from designing an interface that would be more intuitive to the average user than a "native" interface.
And for X there is no native interface, so the point is moot anyway. You may believe that the XUL based interface is a bad design, or is implemented badly, but that it's a "non-native" interface is completly irellevant.
But it all boils down to this: Some people automatically blame XUL for anything that's wrong with Mozilla's performance. It's perfectly possibly XUL has part of the blame, but making the claim just because it's a "non-native" interface without having bothered checking whether XUL is a factor is both meaningless and annoying.
I still like Phoenix, and it does save memory, but make sure you look at the resident set, not virtual pages allocated when you want to judge actual memory usage.
There is no logical reason why a "non-native" interface would have to be slower than a native one. If you look closely, you'll notice that even on Windows lots of applications use "non-native" interfaces, it's just that most of them are made to look as close as possible to what you'd call the "native" interface.
True, the implementation might suck, but if you think it does, then post profiling data. Otherwise, leave the whining to people who do bother to profile it and find the real trouble spots.
But getting accepted by an agent is often just as hard as being published, as the agents don't want to waste their time with works they think will be rejected by publishers.
When it comes to it having to be bad quality not to be published, consider that many highly regarded works were rejected time and time again before a publisher took them on. It's not unusual for books to be rejected by 15-20 publishers before you find someone to publish your work. Most of them will take their time before they respond, if they ever do.
Quite a few people might give up well before that, even if what they've written might well have been a tremendous success if it had been published and marketed properly.
Publishers aren't omniscient. Beatrix Potter self published her childrens books because no publisher would take them on, Emily Bronte's Wuthering Heights was rejected multiple times, Dune was rejected 13 times, M*A*S*H was rejected 21 times, just to take some examples.
And not everyone are in it for the money.
Of course you'll find lots of crap among self-published works, but you'll also find lots of works that are great but just too narrow to find a wide enough audience for a publisber to be interested, and you'll find the occasional work from someone who have given up on the publishers despite having an incredible work...
Doing that with integers is trivial: Keep sums to the tenth of a pence, sum them together, and write your own one line inland_revenue_round() function that rounds the way Inland Revenue requires it.
Same applies for what you're saying. Of course you need to care about rounding, but doing rounding of integer fixed point representations is trivial if you know the rounding rule you need to apply.
But you have to deal with rounding issues and precision with floating point as well, though lots of people don't realize that and screw up because the results are much closer to expected most of the time.
Most people that used fixed point deal with 2-3 decimal points for financial transactions, so precision is rarely an issue. Of course there are always some people with weird requirements. But in particular the guy I replied to brought of business/financial usage where a 32 or 64 bit integer would be more than enough for fixed point with 3 decimals.
When I have, I've never needed anything beyond what I could find in a textbook or online in less than 5 minutes.
Heck, I've practically never even had any reason to use floating point math over that period of time.
Sure, there are lots of areas where you do need maths beyond what you can pick up from a book in 5 minutes, but there are far more where maths is irellevant.
Beyond basic algebra, maths is just another set of domain knowledge that you'll need to aquire to do particular types of software development, not something that is an inherent requirement in order to be a good coder.
Oh, and there are lots of old fixed point code floating around. Looking for "fixed point" instead of "decimal math" might help you find what you want...
It would stick out just as much as with any other projection technology - the problem with projection is being able to project a clear enough image with high light intensity without ending with a ridiculously deep screen. That problem is exactly the same whether you project on fog, a piece of cloth, or your ass...
No, I don't find it ironic, considering that all four of them use RPM. Now referring to Debian, that is ironic, considering that most distros use a different install system that it does.
Rendering models like Java2D, Display Postscript, Display PDF, the X Render model or SVG can all be made to make use of OpenGL with orthographic rendering (z value affect sorting only, not scaling) , as they make heavy use of things like alpha compositing, rendering of polygons, various transformations, and even lighting and other filtering effects (at least SVG). I think you'll see 3D graphics cards being increasingly utilized for normal desktop applications too.
Have you tried Evolution? The only thing remaining I'd consider useful would be new posting and shared calendars/busy-free schedules. Apart from that it interoperates with Exchange very well, though only via IMAP/SMTP. If you want the calendar etc. as well, Ximian have a (proprietary) solution for that.
I'd be very happy to find a storage solution that gave us transfer rates that would get us anywhere near utilizing the full CPU capacity even with entry level servers these days for non-computing intensive processes such as mail delivery, serving DNS queries or fault tolerant message queueing... (and preferrably one that doesn't cost ten times more than any potential savings from reducing the number of servers...)
"Stole" as in "bought the company"? That's a quite interesting definition...
Some models came only with chipram as default.
Running programs from "chipram" was slow, since the CPU was unable to access it and would have to wait whenever any of the other chips accessed it.
When you allocated memory, you could choose to request a specific type of memory (if you needed the memory to be accessible to the auxilliary chips, you'd request chip ram, if you needed the speed you'd request fastram) or not care, in which case fast ram was allocated unless there was no big enough block of fastram available.
Officials of the government passing any judgement about what is a legitimate religion is opening the door for decisions that will deprive people believing in "fringe" religions of rights, simply because most religions out there are considered ridiculous fiction by some group or other.
The question about religion IS essentially meaningless - asking people what they believe and then trying to judge whether or not they have been truthful is something that is incredibly easy to manipulate.
Yeah, I suppose the cost of someone looking at the summary and saying "70.000 Jedi? Surely that must be a joke. Group those 0.37% in with the 'other' category" would be horrendous when amortized over all the tax payers.
Ultimately I doubt the census bureau will try to do anything, as it is next to impossible to prove anything about a religion - after all a religion is based on faith and beliefs, not proofs, and any attempt to push people on it might lead to uncomfortable decisions affecting "real" religions...
Actually, in Britain both are used, but calling 1.000.000.000 a billion is the most "modern" usage. While millard is legal English, it's not very common anymore. In French and Norwegian for instance, milliard is still commonly used for 1.000.000.000, though, and billion for 1.000.000.000.000
The computing power and graphics capabilities delivered by the Amiga and Atari in particular went rings around the PC for a lower price for a long time.
I remember gloating over how slow and expensive my fathers 4.77MHz PC ran compared to my Amiga 500 that was a lot faster, had proper graphics and multitasking and cost less than a third even if you factored in a harddisk.
It was first after the PC dominated in business, and gaming capabilities of the PC started getting comparable to the home computers that the PC began doing serious inroads in the home market, and then the competition got important as it allowed faster price drops in the PC market than among the home computer manufacturers.