The grand poster wrote that it happened 10 years ago, not that the kid was 10 yeas old.
Re:Weirdest April 1st Ever!
on
ISO Approves OOXML
·
· Score: 5, Informative
Could there be some sort of challenge or appeal coming?
According to ISO press release , "Subject to there being no formal appeals from ISO/IEC national bodies in the next two months, the International Standard will accordingly proceed to publication". So there's still 2 months for appeals from NB's.
I don't mean to sound like format correctness Nazi, but your PDFs could be much, much smaller.
You just need to substitute the Nimbus family of fonts (which are in Type 1 format) for some corresponding TTF fonts, like the FreeSans/FreeSerif families.
The problem is that OpenOffice PDF exported currently cannot do subsetting for Type 1 fonts, only for TTF fonts. So it embeds the full Type 1 fonts (Nimbus in your case) in the file. All the characters, including unused ones, like Japanese, Hindi and Chinese glyphs!
That's why your PDFs are almost 1 megabyte when in fact they could be twice as small.
Look in the properties of your PDFs (or use pdffonts utility) - when your see font names like "DAAAAA+font_name" then it's good - they are subsetted.
But font names that aren't prefixed with those "?AAAAA+" strings are embedded fully, without subsetting - they occupy lots of space!
Eliminate those fonts from your document when exporting to PDF, until OpenOffice issue 46305 is resolved (not likely in the near future...).
...leaked the results to the 2008 presidential race...
So it's over 8 months to the election day, and the winner has already been decided? Didn't know it's that bad with democracy in your poor little country already!
I don't want to repeat all the arguments that have been used ad nauseum on Slashdot, so I'll try something hopefully new:
When compared to XP, Linux GUI applications are noticeably slower than on Windows.
The SAME applications, e.g. Firefox 1.5.0.3 on Windows XP and Ubuntu Dapper Drake (so that you don't troll me about not trying the latest Firefox 3 nightlies which should be much faster). The same goes for OpenOffice, the Gimp etc. Of course native Windows apps used with Wine are even worse because of the API emulation overhead.
It seems that either QT, or GTK2, or both, or maybe X11 itself have inferior performance WRT to rendering the user interface, or maybe GCC doesn't do sufficient work with code optimization. The result for the end user is that on the same machine Linux works SLOWER.
Especially, since in most languages, it's papa, not dada.
However, although in my language it's papa and I'm currently teaching my son to pronounce it consciously, he started with "dada" earlier than "papa". The plural of "anecdote" is not "data", of course, but it seems that at least for him "dada" was available earlier.
I thought about this myself. One possible solution that I considered would be to maintain a local list of files on your server and their CRC/Hash values. A script on the server would scan all the files and output a similar list than you could then check against your local copy and would quickly identify any new or changed files. This could be set to a cron job to do periodic scans or just initiate a manual scan whenever.
Congratulations! You have just described Tripwire.
Joel Spolsky's User Interface Design for Programmers points out numerous user interface design issues that are non-obvious to programmers. I highly recommend it.
Besides, with a perfectly good, free, open source alternative (i.e. OpenOffice) why should anyone put their data at risk by using some web based application?
BTW, I suspect that, after acquiring Groove, Microsoft is hard at work trying to implement RTCE in MS Office (although it had already been implemented for MS Word independently of Microsoft in CoWord by Nanyang Technological University in Singapore).
The OpenOffice community seems not to notice or understand the need for this functionality. They better started designing and coding this right away, since OpenOffice may soon find itself years behind technologically-wise (some may half-jokingly mention it already is).
This allows me to sync with a desktop/laptop calendar...
It doesn't cover your tasks nor contacts. It's calendar-only. Yes, open protocols suffer from lack of general, abstracted architecture for groupware - they're all patchwork, stitched together. You can use CalDav for calendar, LDAP for address books (theoretically - no useful implementations of this idea exist), IMAP + SMTP for mail, etc. As a result, each type of object has to be handled completely differently on both the server and client sides. Maybe that's the cause of lack of proper OpenSource groupware solutions - there's no single, standard, open, all-purpose groupware protocol to base them on.
To add insult to injury, I'd like to point out that MS Exchange+Outlook is not only about calendaring. It's also about:
Tasks
Contacts
Notes
Journal entries
Instant messaging
Custom forms for distributing and collecting information,
everything abstracted at some level so you can:
give access to those elements to other coworkers with a unified interface
create custom views to visualize sets of those types of objects in various ways (e.g. you can display calendar events on a timeline view, similarly to how journal entries are shown by default)
use public folders with them (well, not anymore - the functionality deprecated...) and have user-controllable ACLs on everything
Plus lots of additional usability features that OpenSource community failed to replicate, e.g.:
real-time bidirectional client-server communication (server can notify the client instantly about a change in a folder - e.g. a new meeting added by someone else who has proper permissions to the folder you're in)
a nice client-side UI for managin server-side mail filters
ability to control permissions about who can send mail in whose name (without admin intervention)
Isn't CalDav protocol polling-based (which is practically unavoidable with protocols built on HTTP)?
You cannot have the server instantly notify the client about e.g. a new object (e.g. meeting) placed in one of the available workspaces (e.g. calendars, either personal or shared).
Instead, your client periodically polls the server for new data, which is quite ineffective and you don't see changes made by other people instantly.
It's also a source of significant load on the network when you start talking thousands of clients.
I'd disagree with Brad Taylor's statement about GMail's filters being so effective.
In my case almost everyday 1-3 phising messages go through straight to my inbox. Some with quite typical, repetitive subject lines. They are instantly recognizable.
I always use the "report phishing" drop down, I also submit message sources to CastleCops PIRT.
I think that GMail's anti-phishing filter still has a lot of space for improvement.
Of course, I'm not a typical user, I don't hide my e-mail address from the web, and (like Brad) I'm interested in spam professionally, so I want to have a significant sample of it. But I would prefer it get automatically directed into the proper subfolder.
The corporate mail system I'm admining has a higher efficiency spam filter than GMail's in this regard.
BTW, I'm puzzled why spammers backed off from the image spam. I understand that OCR filters forced them to make obfuscated images to a state of barely readable for the less intelligent populace (their main target), but they still didn't try chopping the spam image into small chunks placed in CIDs that would be composed together using an HTML table. This would make OCR-ing much harder, since the filter would first have to render HTML into a bitmap representation... Maybe they will try that in the future. When they do, I doubt GMail's filter will be instantly able to handle this well...
You seem to be approaching the need for big disks from a purely sysadmin point of view. In my case, and the case of a lot of friends/family, massive media collections aren't the exception, they're the rule.
As a happy father of an eight months old toddler, I can confirm that. I've discovered to my terror that only 2 minutes of raw DV video data stream occupy 400MB of storage space! And that's for non HD content! Indeed, a home drive has only two natural states: new and full.
Imagine a 10Tb HDD built in the classic 3.5" wide form factor, with 256Gb of 1024-bit-wide 150MWord/sec flash memory or MRAM on the controller board acting as cache.
Isn't PRAM memory seen as a successor to flash memory in near future? Flash is much less reliable and much slower WRT write operations...
Actually I live in Poland and we call them "jaja wielkanocne", but I know the correct spelling. My fingers, on the other hand (no pun intended) sometimes exhibit symptoms of having a memory of their own...
IMHO the future direction taken with Kerberos should be merging the protocol into LDAP (e.g. for the future LDAPv4 revision of LDAP protocol).
Here's my rationale behind this:
The problem with Kerberos being a distinct protocol from LDAP is that the distinction causes lots of confusion among the implementors, system architects, developers and administrators. This results in lots of cases where the two protocols are misused.
The correct distinction should be that you use Kerberos for authentication (that is, proving that a user is someone he claims to be) and LDAP for authorization (that is, given an authenticated user, determining information related to granting access to some resources - such as group memberships, possibly some application-specific ACLs etc) and for other data for which a directory is useful (hard to list all possible uses of LDAP, but e.g. mail aliases are a fine example).
But because the protocols are separate and very hard to setup together on a single authentication/authorization/directory server (or a group of servers!), people go along with only one of them, usually using LDAP for authentication instead of Kerberos (see mod_auth_ldap for Apache), effectively prohibiting themselves from implementing usable single sign-on
For an example, let's have a look at available OSS solutions. Apache Directory has Kerberos and LDAP integrated from the start, but it's painfully slow as a server at its current state. A mail server using LDAP for aliases can perform quite a bit of hammering on the LDAP server. MIT Kerberos cannot use LDAP databases. So doesn't Shishi Kerberos, although they plan implementing this in the future. That leaves us with Heimdal Kerberos. Heimdal requires the LDAP server to be on the same machine and support LDAPI connections. So that rules out Fedora Directory Server, whose stable version 1.0.4 doesn't support LDAPI yet (although the CVS development version recently got LDAPI support, finally).
I've tried setting up a Heimdal Kerberos server with OpenLDAP (with SASL2 daemon in the middle), and succeeded, but it was a royal pain in the *ss.
All HOWTOs I've found on the web described a brain-dead design where Kerberos maintains a classic file-based database on its own, separate from OpenLDAP database, and one has to make sure they both are in sync (because it's possible that one can have a user that the other doesn't). In such a setup replication is really troublesome and has to be done using 2 different channels and mechanisms (e.g. LDAP syncrepl + Kerberos' own redundant servers).
I wanted an integrated design, where Heimdal stores its data directly in OpenLDAP.
This way, I couldn't possibly create a Kerberos account without an LDAP account (well, I could if I omitted Kerberos objectclass and attributes, but it would be harder to do and easier to detect). Also, I could use only LDAP's replication mechanisms and easily provide fault-tolerant cluster of LDAP and Kerberos servers.
Unfortunately, the diagram for this setup looks quite daunting for a beginner implementor, as you can see for yourself.
There were also lots of gotchas:
Heimdal can connect to LDAP as its database only using LDAPI - a networkless LDAP connection over UNIX domain socket. So you have to configure OpenLDAP in a quite non-standard way, and latest
And is not afraid to go against the labels' will, e.g. see the history behind an eastern egg on the "Broken" album:
They(tvt)wanted a more commercial album and insisted on producers doing his next album. When Trent refused, they told him his album would never get made nor released and denied studio time. The entire Broken album in turn was recorded and written almost entirely while on tour for Pretty Hate Machine. Trent even talks about how they would mix it in hotel rooms,on computers, and hide the names of the song and material with saved names like "pussyfuck".
It's worth noting that ejabberd is written in Erlang.
For those who haven't heard about it, it's an open source, distributed, fault-tolerant instant messaging server (Jabber/XMPP), modular and very configurable and is readily available in most Linux distributions' repositories.
It's one of the most promiment erlang-based projects.
In the latest JDK7 build, they even fixed the "mixing heavyweight and lightweight" z-order problem, so you can mix native AWT widgets into a lightweight Swing UI.
A little offtopic, I've always considered the heavyweight/lightweight terminology for AWT/Swing to be backwards. All the people I know initially confuse those. Swing looks more heavy with respect to both its API and user experience, yet it's called "lightweight" when compared to the "heavyweight" AWT (which runs faster and has simpler API).
I understand that this is in relation to the cross-platform unifomity (where Swing should be easier), if I remember correctly, but gosh, this is so counter-intuitive naming.
On the contrary, MS with.NET understands that the developers are humans too and tries not to confuse them since the sheer enormity of today's families of technologies makes them complex and hard to grasp, no need to make it harder with strange naming conventions (yes, I know that they have mess too, but it seems that with.NET they try to redo Java in a more developer-friendly way).
I'm still preferring Java, though, since it feels more open and multi-cultural (you can feel the legacy of Netscape, Sun, IBM cooperation from old times in there...).
Slashdot Mirror
Man, it's getting ridiculous if this article has rotten in moderation queue for 12 days.
...is the StorageReview.com Hard Drive Reliability Survey: http://www.storagereview.com/map/lm.cgi/survey_login
You basically input all the hard drives you possess into their database and then they let you see the statistics collected so far.
When one of your drives fail, you ought to update its status (at what age has it failed).
The database still contains a bit sparse information, but it's still the best I could locate on the Internet.
How old was the kid? Somehow other posters got the idea he was 10.
The grand poster wrote that it happened 10 years ago, not that the kid was 10 yeas old.
According to ISO press release , "Subject to there being no formal appeals from ISO/IEC national bodies in the next two months, the International Standard will accordingly proceed to publication". So there's still 2 months for appeals from NB's.
I don't mean to sound like format correctness Nazi, but your PDFs could be much, much smaller.
You just need to substitute the Nimbus family of fonts (which are in Type 1 format) for some corresponding TTF fonts, like the FreeSans/FreeSerif families.
The problem is that OpenOffice PDF exported currently cannot do subsetting for Type 1 fonts, only for TTF fonts. So it embeds the full Type 1 fonts (Nimbus in your case) in the file. All the characters, including unused ones, like Japanese, Hindi and Chinese glyphs!
That's why your PDFs are almost 1 megabyte when in fact they could be twice as small.
Look in the properties of your PDFs (or use pdffonts utility) - when your see font names like "DAAAAA+font_name" then it's good - they are subsetted.
But font names that aren't prefixed with those "?AAAAA+" strings are embedded fully, without subsetting - they occupy lots of space!
Eliminate those fonts from your document when exporting to PDF, until OpenOffice issue 46305 is resolved (not likely in the near future...).
...leaked the results to the 2008 presidential race...So it's over 8 months to the election day, and the winner has already been decided? Didn't know it's that bad with democracy in your poor little country already!
I don't want to repeat all the arguments that have been used ad nauseum on Slashdot, so I'll try something hopefully new:
When compared to XP, Linux GUI applications are noticeably slower than on Windows. The SAME applications, e.g. Firefox 1.5.0.3 on Windows XP and Ubuntu Dapper Drake (so that you don't troll me about not trying the latest Firefox 3 nightlies which should be much faster). The same goes for OpenOffice, the Gimp etc. Of course native Windows apps used with Wine are even worse because of the API emulation overhead.
It seems that either QT, or GTK2, or both, or maybe X11 itself have inferior performance WRT to rendering the user interface, or maybe GCC doesn't do sufficient work with code optimization. The result for the end user is that on the same machine Linux works SLOWER.
However, although in my language it's papa and I'm currently teaching my son to pronounce it consciously, he started with "dada" earlier than "papa". The plural of "anecdote" is not "data", of course, but it seems that at least for him "dada" was available earlier.
Congratulations! You have just described Tripwire.
Joel Spolsky's User Interface Design for Programmers points out numerous user interface design issues that are non-obvious to programmers. I highly recommend it.
Real time collaborative editing?
BTW, I suspect that, after acquiring Groove, Microsoft is hard at work trying to implement RTCE in MS Office (although it had already been implemented for MS Word independently of Microsoft in CoWord by Nanyang Technological University in Singapore).
The OpenOffice community seems not to notice or understand the need for this functionality. They better started designing and coding this right away, since OpenOffice may soon find itself years behind technologically-wise (some may half-jokingly mention it already is).
It doesn't cover your tasks nor contacts. It's calendar-only. Yes, open protocols suffer from lack of general, abstracted architecture for groupware - they're all patchwork, stitched together. You can use CalDav for calendar, LDAP for address books (theoretically - no useful implementations of this idea exist), IMAP + SMTP for mail, etc. As a result, each type of object has to be handled completely differently on both the server and client sides. Maybe that's the cause of lack of proper OpenSource groupware solutions - there's no single, standard, open, all-purpose groupware protocol to base them on.
Anybody care to design one?
BTW, eGroupWare might be close functionality-wise on most fronts (on project management it's even better than MS Exchange which doesn't do it at all).
But it's still weak if you need disconnected operation, caching and real-time notifications from server to client.
To add insult to injury, I'd like to point out that MS Exchange+Outlook is not only about calendaring. It's also about:
everything abstracted at some level so you can:
Plus lots of additional usability features that OpenSource community failed to replicate, e.g.:
Isn't CalDav protocol polling-based (which is practically unavoidable with protocols built on HTTP)?
You cannot have the server instantly notify the client about e.g. a new object (e.g. meeting) placed in one of the available workspaces (e.g. calendars, either personal or shared).
Instead, your client periodically polls the server for new data, which is quite ineffective and you don't see changes made by other people instantly.
It's also a source of significant load on the network when you start talking thousands of clients.
I'd disagree with Brad Taylor's statement about GMail's filters being so effective.
...
In my case almost everyday 1-3 phising messages go through straight to my inbox. Some with quite typical, repetitive subject lines. They are instantly recognizable.
I always use the "report phishing" drop down, I also submit message sources to CastleCops PIRT.
I think that GMail's anti-phishing filter still has a lot of space for improvement.
Of course, I'm not a typical user, I don't hide my e-mail address from the web, and (like Brad) I'm interested in spam professionally, so I want to have a significant sample of it. But I would prefer it get automatically directed into the proper subfolder.
The corporate mail system I'm admining has a higher efficiency spam filter than GMail's in this regard.
BTW, I'm puzzled why spammers backed off from the image spam. I understand that OCR filters forced them to make obfuscated images to a state of barely readable for the less intelligent populace (their main target), but they still didn't try chopping the spam image into small chunks placed in CIDs that would be composed together using an HTML table. This would make OCR-ing much harder, since the filter would first have to render HTML into a bitmap representation... Maybe they will try that in the future. When they do, I doubt GMail's filter will be instantly able to handle this well
The conversation sounds unsane...
As a happy father of an eight months old toddler, I can confirm that. I've discovered to my terror that only 2 minutes of raw DV video data stream occupy 400MB of storage space! And that's for non HD content! Indeed, a home drive has only two natural states: new and full.
Isn't PRAM memory seen as a successor to flash memory in near future? Flash is much less reliable and much slower WRT write operations...
Actually I live in Poland and we call them "jaja wielkanocne", but I know the correct spelling. My fingers, on the other hand (no pun intended) sometimes exhibit symptoms of having a memory of their own...
IMHO the future direction taken with Kerberos should be merging the protocol into LDAP (e.g. for the future LDAPv4 revision of LDAP protocol).
Here's my rationale behind this: The problem with Kerberos being a distinct protocol from LDAP is that the distinction causes lots of confusion among the implementors, system architects, developers and administrators. This results in lots of cases where the two protocols are misused.
The correct distinction should be that you use Kerberos for authentication (that is, proving that a user is someone he claims to be) and LDAP for authorization (that is, given an authenticated user, determining information related to granting access to some resources - such as group memberships, possibly some application-specific ACLs etc) and for other data for which a directory is useful (hard to list all possible uses of LDAP, but e.g. mail aliases are a fine example).
But because the protocols are separate and very hard to setup together on a single authentication/authorization/directory server (or a group of servers!), people go along with only one of them, usually using LDAP for authentication instead of Kerberos (see mod_auth_ldap for Apache), effectively prohibiting themselves from implementing usable single sign-on
For an example, let's have a look at available OSS solutions. Apache Directory has Kerberos and LDAP integrated from the start, but it's painfully slow as a server at its current state. A mail server using LDAP for aliases can perform quite a bit of hammering on the LDAP server. MIT Kerberos cannot use LDAP databases. So doesn't Shishi Kerberos, although they plan implementing this in the future. That leaves us with Heimdal Kerberos. Heimdal requires the LDAP server to be on the same machine and support LDAPI connections. So that rules out Fedora Directory Server, whose stable version 1.0.4 doesn't support LDAPI yet (although the CVS development version recently got LDAPI support, finally).
I've tried setting up a Heimdal Kerberos server with OpenLDAP (with SASL2 daemon in the middle), and succeeded, but it was a royal pain in the *ss.
All HOWTOs I've found on the web described a brain-dead design where Kerberos maintains a classic file-based database on its own, separate from OpenLDAP database, and one has to make sure they both are in sync (because it's possible that one can have a user that the other doesn't). In such a setup replication is really troublesome and has to be done using 2 different channels and mechanisms (e.g. LDAP syncrepl + Kerberos' own redundant servers).
I wanted an integrated design, where Heimdal stores its data directly in OpenLDAP.
This way, I couldn't possibly create a Kerberos account without an LDAP account (well, I could if I omitted Kerberos objectclass and attributes, but it would be harder to do and easier to detect). Also, I could use only LDAP's replication mechanisms and easily provide fault-tolerant cluster of LDAP and Kerberos servers.
Unfortunately, the diagram for this setup looks quite daunting for a beginner implementor, as you can see for yourself.
There were also lots of gotchas:
And is not afraid to go against the labels' will, e.g. see the history behind an eastern egg on the "Broken" album:
It's worth noting that ejabberd is written in Erlang.
For those who haven't heard about it, it's an open source, distributed, fault-tolerant instant messaging server (Jabber/XMPP), modular and very configurable and is readily available in most Linux distributions' repositories.
It's one of the most promiment erlang-based projects.
A little offtopic, I've always considered the heavyweight/lightweight terminology for AWT/Swing to be backwards. All the people I know initially confuse those. Swing looks more heavy with respect to both its API and user experience, yet it's called "lightweight" when compared to the "heavyweight" AWT (which runs faster and has simpler API).
I understand that this is in relation to the cross-platform unifomity (where Swing should be easier), if I remember correctly, but gosh, this is so counter-intuitive naming.
On the contrary, MS with .NET understands that the developers are humans too and tries not to confuse them since the sheer enormity of today's families of technologies makes them complex and hard to grasp, no need to make it harder with strange naming conventions (yes, I know that they have mess too, but it seems that with .NET they try to redo Java in a more developer-friendly way).
I'm still preferring Java, though, since it feels more open and multi-cultural (you can feel the legacy of Netscape, Sun, IBM cooperation from old times in there...).