Huh? What socket interface? Where did that come from? WTF are you ranting about now?
I was simply trying to point out that you were mistaken in your belief that "errno" was not thread safe. It is. That's it. If you want to argue that point, sure, go for your life.
If you're trying to make the point that MS's error messages are crap, well, I'm with you there. I never attempted to claim otherwise.
If you want to head off on a tangent that the BSD C API for sockets, later adopted by POSIX and Win32, is crap, well, I'll probably contest that one, but 1) it would be nice if you stuck to one topic at a time in a thread instead of just bringing random crap up without any precedent at all, and 2) be prepared to suggest a better alternative.
i.e. there's a function which returns a pointer to a static, but per-thread thread-local, errno variable. The errno macro dereferences this pointer, so that reading from and assigning to "errno" still works as expected, but is a completely thread-safe manner.
Javascript is a beautiful, elegant, small and generally well-formed language. It has a couple of warts, but what language doesn't.
However, the way that Javascript interacts with web browsers, web pages and all other things web-like is a disgusting, crufty, bloated piece of shit. The DOM bindings are horrible, as far as they go, and they're woefully incomplete. The browser deficiencies in their implementations of the DOM bindings, and the browser-specific work-arounds needed to circumvent said deficiencies, are Lovecraftian nightmares.
(The willful violation of the javascript object model for document.all in HTML5 (see bottom of page) is one particularly nasty example of what the web has done/is doing to Javascript. If you know the JS object model well, think about what that violation really entails, and what it would take to write that special case into a JS engine, for one particular property, of one particular object, if you happen to be running in a particular environment (browser))
Getting Javascript out of the browser would be the best thing that could possibly happen to Javascript.
Except you have to have a way to add programs to the whitelist. Either programatically for "real" apps to do it in their installer, which is useless because the malware will just add itself to the whitelist. Or via a system-enforced dialog for the user along the lines of "warning: The new 'dancing-pigs.exe' program you downloaded wants to run. Allow? Y/N", which... is just as useless.
Nice thought experiment, but I preferred the version that Damon and Affleck wrote about missing the 1975 Red Sox World Series game, with Pudge Fisk hitting the home run and the crowd charging the field, in order to "go see about a girl".
And porting consists of re-compiling and linking to different libraries. I don't think any software developer will have much trouble doing this.
Except that Windows developers have a *really* bad habit of assuming that everything is a little-endian x86-32, because that's all they've ever had.
Heck, it even catches some experienced *nix developers out every now and then, that apps will have strange bugs on platforms the developer doesn't own, even if they *try* to make their code architecture neutral. Most of the Windows software I've seen doesn't even try to make itself portable. Even "porting" to something as similar as x86-64 has exposed plenty of bugs in a fair amount of Windows software. And you think recompiling on ARM is going to "just work"?
There's a version of/. that only contains the interesting stories and actually follows the RFCs?!? How do I sign up without changing my passphrase to something less than 40 characters?
Shit. Debian upgrades go smoothly from one version to the next. I've had the same install upgraded through over 3 versions over the last... uh... few years without a single hitch. How do Canonical manage to fuck it up like that?
WTF? According to the referenced MS blog post, the 650Gb is user data. Why in the world would upgrading your OS and installed apps depend on the amount of per-user data you had? Why is the system updater even bothering to look in the per-user directories?
The keyword there is *can*. Yes, it *can* add expressiveness to your email. In my experience, most of the time it does not. For about 98% of HTML emails I receive it just adds meaningless noise in the form of horrid fonts, freakishly large or small font sizes, garish colours and completely pointless logo image attachments. (The other 2% of the time it merely adds nothing.) I want to read the text of your email in the font of my choosing, at the size I find comfortable, in colours that don't give me headaches. As for your company logo which you attach to *every* *single* *email* - yeah, that's not at all completely pointless.
Oh, you could use *bold*, or/italic/, or _underlines_, but my "plain text" email reader will add bold, italic or underline highlights if it sees the preceding markup, which was in popular use at least 5 years before HTML was invented, and about 10 years before the first version of Outlook - the mail client from hell that actively subverted all the tried-and-tested "good practice" conventions for making email actually productive - was ever released and popularised HTML email.
So, uh, how exactly does HTML email improve communication again? Because I don't see it. I've never felt the desire to bother, and every email I've received where it being in HTML has made a difference, it's been for the worse.
Why not just write the important points at the top as a sort of executive summary. Use bullet points if you want. Or a small collection of one or two sentence paragraphs. Or just one paragraph with all the important points. Then write out the justification in more detail below.
Low attention span people don't even have to scroll down to see your important points, which still get covered before they lose interest. Those wishing to read on may do so.
Your "createOmelet" program is producing way too much useless output for the default non-verbose case. You should really leave the "Cutting Sausage" and "Shredding Cheese" off unless the user puts a "-v" on the command line. As for the "..." output, that's should definitely require "-v -v" (very verbose)
KDE and gnome both exist, but [...] the API is still changing and breaking backwards compatibility regularly.
That is complete bollocks.
The point of the major version number in nearly every piece of Free Software ever is as a marker of backwards compatibility. Version x.y+n will be backwards-compatible with version x.y, for arbitrary n.
If backwards compatibility is broken, that is invariably a bug, and you will usually find version x.y+n+1 released within a day or two fixing back-compatibility. The broken version will rarely make it to any distro's repositories, with the rare exception of something like Debian experimental, which is truly for those who are technically capable, brave of heart, and wish to put themselves in a position to spot bugs like this and kill them before they get close to anything like a normal user.
KDE 3.0.0 was released in April 2002, over 7 years ago. All versions of KDE3 have remained backwards-compatible to that version. Any program written for KDE 3.0.0 will run fine on KDE 3.5.10 (released August 2008). KDE have released KDE 3 updates throughout the KDE 4 development process, and KDE 3 is co-installable with KDE 4. Your KDE 3 apps are guaranteed continue to work correctly under KDE 4, and the libraries they depend upon are not going to break backwards-compatibility *ever*. You can continue to write new KDE 3 apps if you like; they will work fine on old and new KDE desktops.
KDE 4 has similar guarantees about the stability and backwards-compatibility of new releases with respect to KDE 4.0.0.
Gnome 2.0 was released in June 2002, and all versions since then have maintained strict backwards compatibility with it. Any program written for Gnome 2.0 will work fine on Gnome 2.26, released in March 2009. I don't have that much data on Gnome 3 (I don't follow it's development) but there is no way that it could possibly cause Gnome 2 apps to break - absolutely *no-one* would use it if it did. You are free to write new Gnome 2 apps, and they will work for the indefinite future.
Alternatively, if a company will not sell you a font under terms that you consider acceptable, you can simply not use that font and find another.
Yes, EULAs and DRM are licensing nightmares, but that doesn't make all software licensing a nightmare, it just makes software licensing for software that uses EULAs and DRM a nightmare. Fortunately, you have the choice to just ignore such software and take your business elsewhere.
It's only a nightmare if you choose to make it so. It it not at all implied by, or a necessary by-product of, the CSS @font-face attribute.
You can download programs from the web too. Copyright licensing on them is clear. If you ask a server for a copy of a program, and the server is authorised by the copyright holder to give out copies in response to such requests, then again you have a legitimate copy of that program on your computer. You are free to use it as you please[0]. You are free to make use of the output of the program[1]. But again you are not allowed to redistribute the program without the permission of the copyright holder.
The licensing is simple and clear, and I see no reason that anyone should think it "a nightmare".
[0] Unless you have already voluntarily agreed to abide by an extra contract (e.g. an EULA) which limits your rights more that copyright itself does. [1] Except in rare cases where the output of the program includes part of the program (or associated data) itself, in which case those parts will be under copyright. (e.g. Bison, which contains a special exception to allow you to use such parts.)
"So, in reality, you will not be able to get a license to make an expensive font file available on the web."
Right, in which case you just use a font that you can get a license for, such as a screen-optimised version, or a free alternative.
i.e. you only distribute bits that you have a license to distribute. If you cannot get a license, you do not distribute at all, or you find an alternative. Which is how it works for images, MP3s, video and every other sequence of bits there is.
Still seems very straightforward and non-nightmareish to me.
"The copyright status of works created with the font is why."
Can you expand on this? If I create a an ODF document, or a local HTML file on my PC, or a banner image using a font, none of those works will *contain* the font. The first two will contain references to the font, and the last will contain a picture of some of the glyphs rendered at a particular resolution, as if I had taken a picture of a poster in the real world which used that font. None of those works actually contain "the font".
If I distribute those works - the ODF file, the HTML file, or the image - I am not distributing the font, so why is the copyright status of that work at issue? In the case of the first two, the work - that is, the content - will simply be rendered in a different font if the recipient does not have their own licensed copy of the font. In the third, it still looks the same, but is entirely my own work with my own copyright. The copyright status is clear in all cases.
If I decide to publish the HTML file on my web server, then to publish just the HTML, the copyright status is still clear.
If I want to reference the font with an @font-face CSS style, and redistribute the font itself from my web server, then again, copyright is very clear. I need a license to do so from the copyright holder of the font. If I do hot have such a license, I cannot redistribute the font, and the HTML document will have to fall back to another font. Big deal.
Still don't see where the complexity is, or why it's "a nightmare".
"If you download font files with a web page, there's nothing keeping you from using that font file to create print documents."
Yes. So what?
"For that reason it is unlikely that we will see professional print-quality fonts licensed in a way which allows them to be served with a web page."
So, you're saying that font foundaries are unlikely to make their fonts available to website developers, on terms that will allow those websites to redistribute them.
Which simply means that websites simply will not be able to use those fonts, and will have to pick different fonts to use that they can get redistribution rights for.
How is this "a nightmare"? Some copyright holders are unwilling to grant other people a license to redistribute some of their works. Some are willing, for some works. That just how things are with other sequences of bits!
"Now you could move that copy to your system font directory."
And you could save a copy of an image you downloaded from the web to/usr/local/share/images instead of/home/[user]/Desktop/downloads. So?
"You could direct anyone else who needs the font to go to the same website you got yours from and move it to your system font directory in the same way."
And you could direct anyone who likes the image you downloaded to the same website you downloaded the image from.
"So if any one website uses a font, everyone has access to a free font download."
Yes, if a website puts up a font for download, and serves it up to anyone who asks for it (e.g. without doing "referrer" or cookie checking), then anyone can download it. Just as if a website puts up an image for download then anyone can download it.
I must be really thick, as I still don't understand where the problem is.
Slashdot Mirror
Huh? What socket interface? Where did that come from? WTF are you ranting about now?
I was simply trying to point out that you were mistaken in your belief that "errno" was not thread safe. It is. That's it. If you want to argue that point, sure, go for your life.
If you're trying to make the point that MS's error messages are crap, well, I'm with you there. I never attempted to claim otherwise.
If you want to head off on a tangent that the BSD C API for sockets, later adopted by POSIX and Win32, is crap, well, I'll probably contest that one, but 1) it would be nice if you stuck to one topic at a time in a thread instead of just bringing random crap up without any precedent at all, and 2) be prepared to suggest a better alternative.
*shrug*
errno is completely thread-safe on all modern platforms. errno is allowed to be a macro, and often looks like
#define errno (*get_pointer_to_per_thread_errno())
i.e. there's a function which returns a pointer to a static, but per-thread thread-local, errno variable. The errno macro dereferences this pointer, so that reading from and assigning to "errno" still works as expected, but is a completely thread-safe manner.
Javascript is a beautiful, elegant, small and generally well-formed language. It has a couple of warts, but what language doesn't.
However, the way that Javascript interacts with web browsers, web pages and all other things web-like is a disgusting, crufty, bloated piece of shit. The DOM bindings are horrible, as far as they go, and they're woefully incomplete. The browser deficiencies in their implementations of the DOM bindings, and the browser-specific work-arounds needed to circumvent said deficiencies, are Lovecraftian nightmares.
(The willful violation of the javascript object model for document.all in HTML5 (see bottom of page) is one particularly nasty example of what the web has done/is doing to Javascript. If you know the JS object model well, think about what that violation really entails, and what it would take to write that special case into a JS engine, for one particular property, of one particular object, if you happen to be running in a particular environment (browser))
Getting Javascript out of the browser would be the best thing that could possibly happen to Javascript.
Except you have to have a way to add programs to the whitelist. Either programatically for "real" apps to do it in their installer, which is useless because the malware will just add itself to the whitelist. Or via a system-enforced dialog for the user along the lines of "warning: The new 'dancing-pigs.exe' program you downloaded wants to run. Allow? Y/N", which ... is just as useless.
Nice thought experiment, but I preferred the version that Damon and Affleck wrote about missing the 1975 Red Sox World Series game, with Pudge Fisk hitting the home run and the crowd charging the field, in order to "go see about a girl".
Except that Windows developers have a *really* bad habit of assuming that everything is a little-endian x86-32, because that's all they've ever had.
Heck, it even catches some experienced *nix developers out every now and then, that apps will have strange bugs on platforms the developer doesn't own, even if they *try* to make their code architecture neutral. Most of the Windows software I've seen doesn't even try to make itself portable. Even "porting" to something as similar as x86-64 has exposed plenty of bugs in a fair amount of Windows software. And you think recompiling on ARM is going to "just work"?
Summary is incorrect. He would be disconnected the next time he is alleged to have pirated something.
There's a version of /. that only contains the interesting stories and actually follows the RFCs?!? How do I sign up without changing my passphrase to something less than 40 characters?
I moved away from Demon after the Internet Watch Foundation debacle last December to UK Free Software Network, and have no complaints about any aspect of their service.
Shit. Debian upgrades go smoothly from one version to the next. I've had the same install upgraded through over 3 versions over the last ... uh ... few years without a single hitch. How do Canonical manage to fuck it up like that?
Until Microsoft can get Windows to upgrade cleanly from one release to another, it'll never be ready for the desktop.
WTF? According to the referenced MS blog post, the 650Gb is user data. Why in the world would upgrading your OS and installed apps depend on the amount of per-user data you had? Why is the system updater even bothering to look in the per-user directories?
The keyword there is *can*. Yes, it *can* add expressiveness to your email. In my experience, most of the time it does not. For about 98% of HTML emails I receive it just adds meaningless noise in the form of horrid fonts, freakishly large or small font sizes, garish colours and completely pointless logo image attachments. (The other 2% of the time it merely adds nothing.) I want to read the text of your email in the font of my choosing, at the size I find comfortable, in colours that don't give me headaches. As for your company logo which you attach to *every* *single* *email* - yeah, that's not at all completely pointless.
Oh, you could use *bold*, or /italic/, or _underlines_, but my "plain text" email reader will add bold, italic or underline highlights if it sees the preceding markup, which was in popular use at least 5 years before HTML was invented, and about 10 years before the first version of Outlook - the mail client from hell that actively subverted all the tried-and-tested "good practice" conventions for making email actually productive - was ever released and popularised HTML email.
So, uh, how exactly does HTML email improve communication again? Because I don't see it. I've never felt the desire to bother, and every email I've received where it being in HTML has made a difference, it's been for the worse.
Why not just write the important points at the top as a sort of executive summary. Use bullet points if you want. Or a small collection of one or two sentence paragraphs. Or just one paragraph with all the important points. Then write out the justification in more detail below.
Low attention span people don't even have to scroll down to see your important points, which still get covered before they lose interest. Those wishing to read on may do so.
You can run the programs for any purpose - e.g. to benchmark them, which is forbidden by the EULA of many Windows programs.
You can study how the programs work, and change them to make them do what you wish.
You can legally redistribute copies so you can help your neighbour.
You can improve the programs, and release your improvements (and modified versions in general) to the public, so that the whole community benefits.
You know, little things.
Your "createOmelet" program is producing way too much useless output for the default non-verbose case. You should really leave the "Cutting Sausage" and "Shredding Cheese" off unless the user puts a "-v" on the command line. As for the "..." output, that's should definitely require "-v -v" (very verbose)
That is complete bollocks.
The point of the major version number in nearly every piece of Free Software ever is as a marker of backwards compatibility. Version x.y+n will be backwards-compatible with version x.y, for arbitrary n.
If backwards compatibility is broken, that is invariably a bug, and you will usually find version x.y+n+1 released within a day or two fixing back-compatibility. The broken version will rarely make it to any distro's repositories, with the rare exception of something like Debian experimental, which is truly for those who are technically capable, brave of heart, and wish to put themselves in a position to spot bugs like this and kill them before they get close to anything like a normal user.
KDE 3.0.0 was released in April 2002, over 7 years ago. All versions of KDE3 have remained backwards-compatible to that version. Any program written for KDE 3.0.0 will run fine on KDE 3.5.10 (released August 2008). KDE have released KDE 3 updates throughout the KDE 4 development process, and KDE 3 is co-installable with KDE 4. Your KDE 3 apps are guaranteed continue to work correctly under KDE 4, and the libraries they depend upon are not going to break backwards-compatibility *ever*. You can continue to write new KDE 3 apps if you like; they will work fine on old and new KDE desktops.
KDE 4 has similar guarantees about the stability and backwards-compatibility of new releases with respect to KDE 4.0.0.
Gnome 2.0 was released in June 2002, and all versions since then have maintained strict backwards compatibility with it. Any program written for Gnome 2.0 will work fine on Gnome 2.26, released in March 2009. I don't have that much data on Gnome 3 (I don't follow it's development) but there is no way that it could possibly cause Gnome 2 apps to break - absolutely *no-one* would use it if it did. You are free to write new Gnome 2 apps, and they will work for the indefinite future.
No, no, no!
It's "you'll need to download a PDF reader".
pdfreaders.org even has free icons which you can use to replace the more usual Adobe-based PDF icons.
Alternatively, if a company will not sell you a font under terms that you consider acceptable, you can simply not use that font and find another.
Yes, EULAs and DRM are licensing nightmares, but that doesn't make all software licensing a nightmare, it just makes software licensing for software that uses EULAs and DRM a nightmare. Fortunately, you have the choice to just ignore such software and take your business elsewhere.
It's only a nightmare if you choose to make it so. It it not at all implied by, or a necessary by-product of, the CSS @font-face attribute.
Yes? And?
You can download programs from the web too. Copyright licensing on them is clear. If you ask a server for a copy of a program, and the server is authorised by the copyright holder to give out copies in response to such requests, then again you have a legitimate copy of that program on your computer. You are free to use it as you please[0]. You are free to make use of the output of the program[1]. But again you are not allowed to redistribute the program without the permission of the copyright holder.
The licensing is simple and clear, and I see no reason that anyone should think it "a nightmare".
[0] Unless you have already voluntarily agreed to abide by an extra contract (e.g. an EULA) which limits your rights more that copyright itself does.
[1] Except in rare cases where the output of the program includes part of the program (or associated data) itself, in which case those parts will be under copyright. (e.g. Bison, which contains a special exception to allow you to use such parts.)
"So, in reality, you will not be able to get a license to make an expensive font file available on the web."
Right, in which case you just use a font that you can get a license for, such as a screen-optimised version, or a free alternative.
i.e. you only distribute bits that you have a license to distribute. If you cannot get a license, you do not distribute at all, or you find an alternative. Which is how it works for images, MP3s, video and every other sequence of bits there is.
Still seems very straightforward and non-nightmareish to me.
Well, it won't run on any of my systems then.
Unless I feel like downloading untold megs of 32-bit libraries just to run this one app, just because they won't do a recompile. FFS!
"The copyright status of works created with the font is why."
Can you expand on this? If I create a an ODF document, or a local HTML file on my PC, or a banner image using a font, none of those works will *contain* the font. The first two will contain references to the font, and the last will contain a picture of some of the glyphs rendered at a particular resolution, as if I had taken a picture of a poster in the real world which used that font. None of those works actually contain "the font".
If I distribute those works - the ODF file, the HTML file, or the image - I am not distributing the font, so why is the copyright status of that work at issue? In the case of the first two, the work - that is, the content - will simply be rendered in a different font if the recipient does not have their own licensed copy of the font. In the third, it still looks the same, but is entirely my own work with my own copyright. The copyright status is clear in all cases.
If I decide to publish the HTML file on my web server, then to publish just the HTML, the copyright status is still clear.
If I want to reference the font with an @font-face CSS style, and redistribute the font itself from my web server, then again, copyright is very clear. I need a license to do so from the copyright holder of the font. If I do hot have such a license, I cannot redistribute the font, and the HTML document will have to fall back to another font. Big deal.
Still don't see where the complexity is, or why it's "a nightmare".
"If you download font files with a web page, there's nothing keeping you from using that font file to create print documents."
Yes. So what?
"For that reason it is unlikely that we will see professional print-quality fonts licensed in a way which allows them to be served with a web page."
So, you're saying that font foundaries are unlikely to make their fonts available to website developers, on terms that will allow those websites to redistribute them.
Which simply means that websites simply will not be able to use those fonts, and will have to pick different fonts to use that they can get redistribution rights for.
How is this "a nightmare"? Some copyright holders are unwilling to grant other people a license to redistribute some of their works. Some are willing, for some works. That just how things are with other sequences of bits!
Still don't get it.
"Now you could move that copy to your system font directory."
And you could save a copy of an image you downloaded from the web to /usr/local/share/images instead of /home/[user]/Desktop/downloads. So?
"You could direct anyone else who needs the font to go to the same website you got yours from and move it to your system font directory in the same way."
And you could direct anyone who likes the image you downloaded to the same website you downloaded the image from.
"So if any one website uses a font, everyone has access to a free font download."
Yes, if a website puts up a font for download, and serves it up to anyone who asks for it (e.g. without doing "referrer" or cookie checking), then anyone can download it. Just as if a website puts up an image for download then anyone can download it.
I must be really thick, as I still don't understand where the problem is.