Parent link is definitely worth reading!
Thanks, Absolut-- here's a bigger chuck of the key section:
"For everything sold on iTunes, we get the majority of the 70-79p per unit sale price," he said, then added: "But for everything sold on the Ruckus Network we receive the princely sum of £0.005 per unit. That's half a pence. My distributor then takes their 25 per cent off of that, leaving myself and the artists to dish up the remaining fractions of a penny between us."
It's not much better through Real Networks, he informed - for sales through that service, his label receives a penny per track, he claimed. The thousand tracks sold so far have accrued £10 to the label (to share with the artists) rather than, "the £790 or so we'd have got for the same amount of sales through iTunes."
iTunes also drives business at international distributor of independently-owned music and video catalogues, DMG. Revealing the company's quarterly results, DMG CEO Mitchell Koulouris explained: "In last year's first quarter, approximately 89 per cent of our revenue came from iTunes, less than 5 per cent was from subscription services, and we had no mobile distribution."
It's really interesting to see these kinds of numbers and then weigh what the big labels (was it Universal?) and other content providers like NBC are doing. They're used to being the exclusive channel and in complete control of the profit stream coming from the consumer back towards the artists. Now that new forms of distribution and playback are readily available (especially digital copies which can be format shifted and recompressed to best suit new algorithms and hardware capabilities), I don't think those guys have the leverage they seem to feel they do with regard to forcing price increases.
I doubt that Apple really cares where you get the content. From what the first poster said, Apple is running the iTunes music store on a cost neutral basis. Whether you rip it yourself, D/L it for free (sometimes legally such as etree.org, or sometimes not so legally), buy it from iTunes, or buy it from someone else, what matters is whether you have the content you want and whether the device you use does a good job of playback.
I've been trying to figure out NBC's reasoning: presumably they figure that they'll make more money from paid advertising by making everyone watch the live version or DVR it from a live source than they'll lose by not having the $1.99 commercial-free version being sold. Taken NBC's reported pricing at face value, they want to get something like $5 for thirty minutes of viewer eyeballs-- probably about 22 minutes of content and 8 minutes of ads.
Does this mean that if you could sell your eyeballs directly to those who advertise on NBC, you'd be paid about twice the US minimum wage?!! Woah!
If you've got your earbuds for more than about 2 years, you're probably getting close to the point where the original battery in the iPod is starting to reach the end of it's recharge life. The earbuds Apple ships are OK-- not great, not bad, but like all "ear canal headphone" (ECH) designs, they do provide a fair amount of external noise reduction compared to open "foam" headphones. They actually do reasonably well in noisy environments like on an airplane, even compared with the much more expensive active noise cancelling headphones from Bose, etc.
Most audiophiles will agree that many of the older analog technologies retained a "warm" and sometimes even "saturated" presence in the processing of the audio. There are many digital solutions today that attempt and even come close to reproducing this effect during the recording process or even during the mixing or mastering process of producing audio.
The "warm" or "saturated" sound you mention tends to result from mild distortion consisting of even harmonics, and can indeed be created or reproduced by digital equipment with appropriate feedback circuits to add a little noise back into the signal during processing.
There's nothing wrong with preferring some sonic coloration from your playback equipment, but most engineers try to set up audio equipment which comes as close as possible to reproducing the original inputs with as little extra distortion as possible. That's easier to test for and achieve than to come up with the right level of noise and distortion which an individual might prefer, because the latter is a lot more subjective and variable.
Just remember, people-- you control your machine and where a domain resolves, if at all. If you don't want to get ads from Massive's in-game ad engine, consider setting up the following zone on a nameserver you use:
$TTL 86400
@ IN SOA localhost. hostmaster.localhost. ( 1 ; serial 3h ; Refresh 3 hours 1h ; Retry 1 hour 30d ; Expire 30 days 1d ) ; Minimum 24 hours
@ NS localhost.
localhost A 127.0.0.1
madsever.net. A 127.0.0.1 ad A 127.0.0.1 imp A 127.0.0.1 media A 127.0.0.1
Your dlink box probably also has a 4-port switch. Doesn't mean that routers are switches.
I would agree with almost all of your other points, but every router is at least a two-port switch by definition. If you can't connect the router to two (or more) different networks, then it can't route traffic between them.
Sure, our TV broadcasts have traveled in space for many many lightyears, but they've become incredibly feeble doing so. That, and they're mingled with all the radiation from our sun. The humankind isn't even coming close to using the kinds of energies that are constantly reflected from Earth's surface.
As a counterexample, note that we're able to receive the signals generated by Voyager 1 and 2, from about 100 AU's or about 2% of a light year, which use transmitters sending about 20 watts and of which our Earth-bound antennas only receive a fraction of a milliwatt. We'll probably lose them around year 2020 when their slowly fading RTG power supplies drop the power level below the minimum needed for operation, but that's not because we can't receive their signal so long as they work well enough to send it.
While the majority of radiation being emitted by the earth is indeed thermal infrared as the night side cools, that's in a completely different spectrum from the long-wave radiation emitted by 50 and 60Hz AC power lines, or some of the high-frequency bands such as the 1.42 to 1.64 GHz range known as the "water hole", which turns out to be nearly ideal for interstellar transmissions due to minimal noise from the 3K background radiation:
"0.1CPU-second to do an SSL handshake seems like a huge amount, since this would limit you to ten connections a second. Considering that hardware crypto devices that can handle SSL at over 100Mb/s exist, I'm really surprised that the numbers are that high. Can you cite the system you used to test this?"
The key thing to notice here is that doing the initial key handshake involves 1024-bit RSA or DSA public keys, typically, whereas the number you are quoting is the streaming rate for doing 56/128-bit symmetric encryption via DES, 3DES, or AES. The difference in workload between the initial public-key crypto used to set up a temporary session key as a shared secret, and the workload for doing the subsequent symmetric crypto using this session key is huge.
If you want to understand the difference, try running "openssl speed" on your favorite machine. A ~ 1GHz Intel box can do about 120 1024-bit RSA keys per second; about 20 2048-bit RSA keys per second; or 3.3 4096-bit RSA keys per second. By contrast, it can stream DES at 20MB/s or AES-128 at about 17MB/s.
Your task, should you choose to accept it, is to write your own init program which runs on top of a Linux kernel without using any of the GNU userland utilities or GNU libc.
Of course, this sort of attack has been known for a while, and it's not just OS X which is mostly immune to attempts by a process to yield the CPU just before a tick to avoid having the usage assigned to the process-- if you check the source code in FreeBSD, for example, in:
----added to keep the comment from wrapping onto the URL---- /*
* Clock handling routines.
*
* This code is written to operate with two timers that run independently of
* each other.
*
* The main timer, running hz times per second, is used to trigger interval
* timers, timeouts and rescheduling as needed.
*
* The second timer handles kernel and user profiling,
* and does resource use estimation. If the second timer is programmable,
* it is randomized to avoid aliasing between the two clocks. For example,
* the randomization prevents an adversary from always giving up the cpu
* just before its quantum expires. Otherwise, it would never accumulate
* cpu ticks. The mean frequency of the second timer is stathz. [... ]
What's the difference between "possible" and "actually obtainable"?
Good question.:-)
The former tends to mean what is doable in theory or in practice, but may not correspond to any actual realistic situation. For example, if you stuff nothing but data down the PCI (AGP, PCIe, whatever) bus, you get a rate which is about the bandwidth of the underlying bus, but in reality, you have to do some setup and so forth (ie, configure the target address and size for a DMA transfer) before blasting data bits, and other PCI devices also get to get some bus cycles, so the actually obtainable data rate tends to be about only 90% of the max bandwidth of the bus in practice.
This tends to be applicable to a wide range of things, from ethernet/networking load capacities, to disk I/O performance, to video card framerates, etc....
Agreed, but it has nothing to do with vertical syncing.
What's happening on the Mac is that almost all window draws are done in a double-buffered context, so that any changes first are drawn offscreen, and then only the changed regions actually get blitted into video memory. The classic example of the problem you're seeing on windows is something like a window showing "Downloading at 170K/s", where the entire string keeps flickering because they redraw the whole line on screen, rather than just updating the number if it changes. The Mac approach uses more memory, but it means that you can switch back and forth between two windows which overlay each other and have the obscured sections get immediately blitted rather than needing the app to redraw the obscured parts.
This is used elsewhere, too-- such as in X11 called the "Damage extension"....
I've annoyed a few spamers in the past so I get my domain name in from addresses from time to time so every once in a while I will get a real person with a legit complaint however the postmaster address is now getting several thousand messages a day and I have no choice but to remove it.
I doubt it's anything personal; some spammers grovel through WHOIS records and simply joe-job random domains and set the bounce address to postmaster@ or the listed WHOIS contacts-- and, of course, they also do the traditional scraping of email addys from websites, mailing lists, etc. Setting up SPF records and doing SPF checking does quite a bit to reduce the backscatter from forged email which gets bounced back to you.
Once or twice in drastic cases, I've actually had to use HELO-level checking to reject all mail coming from.ru and.cn domains during a heavy run of forged spam bouncing back to a domain I run, but only for a few days until the domains in question started gaining some clue about SPF.
However, if you reject email delivered to postmaster@your_domain, then your mail system isn't configured right, and you should expect to be blacklisted.
However, the way that my ISP's network is configured, I am able to take any unused IP address on their network for myself, simply by making a minor change in my computer's network configuration. For example, say that I am assigned fixed IP addresses 101.1.1.10 through 101.1.1.20. I can just reconfigure my computer to be IP address 101.1.1.50, and if this address is not currently being used by someone else, I can get it for myself. Similarly, someone else could take one of my assigned IP addresses if it is not currently in use.
This is a good thing to notice and be aware of, but it is fairly normal for ISPs to not put a firewall in place between business-class service at the colo level to verify source addresses and filter out spoofed traffic from other netblocks owned by that ISP.
The trick for this to be useable for anything beyond a mildly cloaked DoS is that you either have to use source routing so that the answers come back to you, or you have to be close enough to the subnet being spoofed that you can fiddle with the router which sends it to that subnet or to yours.
Think of ARP spoofing, think of using ICMP router redirects, think of RIP or BGP advertisements, think of spoofing a VLAN header and waving the magic wand at the switch and claim that your connection is really a trunk port (and then repeat with the ARP spoofing:-).
(hums a banal Woody Guthrie tune)
"This route is YOUR route, this route is MY route, this route is OUR route..."
In Cisco ISO-speak, to do such checking is called "Reverse Path Forwarding". See RFCs 1812 and 2267 and perhaps you can give your ISP a security clue, or take advantage of the opportunities to experiment, depending.:-)
I thought AT&T vs BSD case settled this. Header files aren't protectable.
You're right about publicly published APIs defined in something like a header file do not qualify as grounds for copyright infringement, at least here in the USA (YMMV may vary elsewhere).
On the other hand, nothing requires a vendor to release their private header files to the world, and those may well be copyrighted and marked as "proprietary trade secret information", although that's obviously not applicable to header files under the LGPL.:-)
Of course it gets unclear what happens if header files contain inline functions (whoever puts code to header file should be shot at noon:) but function signatures or class definitions aren't copyrightable code.
You're making a broad generalization here about something that may not be quite so simple, as, if it comes down to a real-world case, then the judge is the one who decides what merits copyright protection and what doesn't.
PS: yes, I missed the slash in my trailing < quote > tags.
PPS: and yep, i used preview, but i thought the reverse-indented quoting looked kinda neat so I decided to leave it as-is. Whoop whoop!
There's a difference between permitting "reverse engineering" and requiring a vendor to publish proprietary specs/APIs/hardware interfaces. Can't you just rip the original CDs to MP3 and go on with life, rather than getting all hot and bothered that your cell phone/Rio/Creative ZEN/whatever can't play AAC?:-)
Anyway, note that reverse engineering to make a system functional is allowed here in the US (even with the DMCA), which means that Linux DVD *players* are OK, but DVD *copiers* or software which can copy a DVD seem to cross the line.
It's flimsy but I suppose you could say that recognizing reported flaws and patching them quickly shows a project or vendor takes security seriously but that is all these vulnerability reports are good for.
With due respect, I have to disagree. If a project or vendor takes security seriously, they'll design the software so that it has zero security bugs.
Almost nobody delivers this for popular commercial software like Windows, Office, etc, but that's more because the people paying for such software seem to not care about security at all, or value new features, convenience, and speed much more than they do security or reliability.
However, people designing control systems for airplanes, hospital medical equipment used in lifesaving situations, and so forth, actually do a fair job of delivering software which has zero security issues. This level of quality isn't undoable for more widely used general-purpose software-- some of DJB's software has close to a perfect security record, for example, but it is rare to find software which was designed from the start with the assumption that no security holes are acceptable.
Especially in the PC world, it's common to find software which is significantly broken in the initial release and needs to be patched before it is even feature-complete, much less close to being "bug free" or "secure"....
Manipulating politicians (who as adults should know better) is one thing, but presenting false or misleading information to our children in the guise of factual instructional materials is especially contemptible.
I certainly agree with you, here. I just have a hard time squaring your concern about this matter with your.sig:
Would it help if I mentioned that I like Fox News and agree with most of what Sean Hannity says?
Maybe we should make sure that children avoid watching Fox?:-)
"Liberty or Death" is a cute slogan, but if you want Liberty, you have to be ready to accept Liberty AND Death.
So? It seems to me that we're all going to experience Death sooner or later regardless-- nobody lives forever. It also seems to me that the quality of the life people live ought to be a lot more important than simply extending the duration, especially people in the terminal stages of cancer or whatnot....
Why can't we have 'email' without SMTP? Or failing that, why can't we at least get a better SMTP?
There were email systems which predated SMTP using TCP/IP transport, such as MMDF over something like UUCP, or DEC's Mail (ie, http://en.wikipedia.org/wiki/Mail-11) which ran either local mode only or over DECnet, using the "::" syntax for explicit hop-to-hop relaying.
These systems had some advantages, in that you typically could only send email to hosts which you had an explicitly configured topology set up for you by an admin. This predated the notion of spam or the notion that people could set up and use a network or cluster of machines without having someone clueful around to supervise and fix problems. Later on, they acquired the notion of Bitnet and ARPA network gateways to transfer mail to foreign systems....
It NEEDS to be torn down and rebuilt from the ground to provide (among other things):
* reliable delivery (Is it there yet?)
The SMTP procotol provides for reliable delivery, but MTAs which fail to adhere to the standard can lose email.
* reliable authentication (Is the sender whom they claim to be?)
This is a moderately hard problem to solve, but it's more an issue with most users being unable or unwilling to use things like PGP/GnuPGP or S/MIME.
* timely delivery (Preferably under 10 minutes to any destination, or the original sender is notified, preferably NOT via email)
The overwhelming majority of email is delivered in under 10 minutes, but if someone's mailserver or Internet connection is down, then mail ain't going to be delivered until the problem gets rectified. I just checked my mailserver logs and out of the 500 emails delivered today, the average delay was about 5 seconds, and the longest delay was 111 seconds.
Off topic, I just found out that even if you preview a post with HTML tags as "Plain Old Text" it still renders the HTML tags properly. On the other hand, regular text still works fine in "Plain Old Text" mode so why isn't this mode used as default?
It's actually a per-user preference.
Click on Preferences from the top nav bar, click on Comments, look down for "Comment Post Mode" to change the default mode that your posts are sent out as. And yes, if you use normal HTML tags from the "allowed" list, then your browser will typically interpret those even within posts sent as "Plain Old Text", but might screw up things like greater-than and less-than signs, too.
Slashdot Mirror
Thanks, Absolut-- here's a bigger chuck of the key section: "For everything sold on iTunes, we get the majority of the 70-79p per unit sale price," he said, then added: "But for everything sold on the Ruckus Network we receive the princely sum of £0.005 per unit. That's half a pence. My distributor then takes their 25 per cent off of that, leaving myself and the artists to dish up the remaining fractions of a penny between us."
It's not much better through Real Networks, he informed - for sales through that service, his label receives a penny per track, he claimed. The thousand tracks sold so far have accrued £10 to the label (to share with the artists) rather than, "the £790 or so we'd have got for the same amount of sales through iTunes."
iTunes also drives business at international distributor of independently-owned music and video catalogues, DMG. Revealing the company's quarterly results, DMG CEO Mitchell Koulouris explained: "In last year's first quarter, approximately 89 per cent of our revenue came from iTunes, less than 5 per cent was from subscription services, and we had no mobile distribution."
It's really interesting to see these kinds of numbers and then weigh what the big labels (was it Universal?) and other content providers like NBC are doing. They're used to being the exclusive channel and in complete control of the profit stream coming from the consumer back towards the artists. Now that new forms of distribution and playback are readily available (especially digital copies which can be format shifted and recompressed to best suit new algorithms and hardware capabilities), I don't think those guys have the leverage they seem to feel they do with regard to forcing price increases.
I doubt that Apple really cares where you get the content. From what the first poster said, Apple is running the iTunes music store on a cost neutral basis. Whether you rip it yourself, D/L it for free (sometimes legally such as etree.org, or sometimes not so legally), buy it from iTunes, or buy it from someone else, what matters is whether you have the content you want and whether the device you use does a good job of playback.
I've been trying to figure out NBC's reasoning: presumably they figure that they'll make more money from paid advertising by making everyone watch the live version or DVR it from a live source than they'll lose by not having the $1.99 commercial-free version being sold. Taken NBC's reported pricing at face value, they want to get something like $5 for thirty minutes of viewer eyeballs-- probably about 22 minutes of content and 8 minutes of ads.
Does this mean that if you could sell your eyeballs directly to those who advertise on NBC, you'd be paid about twice the US minimum wage?!! Woah!
If you've got your earbuds for more than about 2 years, you're probably getting close to the point where the original battery in the iPod is starting to reach the end of it's recharge life. The earbuds Apple ships are OK-- not great, not bad, but like all "ear canal headphone" (ECH) designs, they do provide a fair amount of external noise reduction compared to open "foam" headphones. They actually do reasonably well in noisy environments like on an airplane, even compared with the much more expensive active noise cancelling headphones from Bose, etc.
The "warm" or "saturated" sound you mention tends to result from mild distortion consisting of even harmonics, and can indeed be created or reproduced by digital equipment with appropriate feedback circuits to add a little noise back into the signal during processing.
There's nothing wrong with preferring some sonic coloration from your playback equipment, but most engineers try to set up audio equipment which comes as close as possible to reproducing the original inputs with as little extra distortion as possible. That's easier to test for and achieve than to come up with the right level of noise and distortion which an individual might prefer, because the latter is a lot more subjective and variable.
Nothing wrong with that! If you enjoy a cheap wine the best, why bother spending a lot more for something you don't like as much?
I would agree with almost all of your other points, but every router is at least a two-port switch by definition. If you can't connect the router to two (or more) different networks, then it can't route traffic between them.
As a counterexample, note that we're able to receive the signals generated by Voyager 1 and 2, from about 100 AU's or about 2% of a light year, which use transmitters sending about 20 watts and of which our Earth-bound antennas only receive a fraction of a milliwatt. We'll probably lose them around year 2020 when their slowly fading RTG power supplies drop the power level below the minimum needed for operation, but that's not because we can't receive their signal so long as they work well enough to send it.
While the majority of radiation being emitted by the earth is indeed thermal infrared as the night side cools, that's in a completely different spectrum from the long-wave radiation emitted by 50 and 60Hz AC power lines, or some of the high-frequency bands such as the 1.42 to 1.64 GHz range known as the "water hole", which turns out to be nearly ideal for interstellar transmissions due to minimal noise from the 3K background radiation:
http://www.exploratorium.edu/learning_studio/news/ october97/mainstory5_oct97.html
"0.1CPU-second to do an SSL handshake seems like a huge amount, since this would limit you to ten connections a second. Considering that hardware crypto devices that can handle SSL at over 100Mb/s exist, I'm really surprised that the numbers are that high. Can you cite the system you used to test this?"
The key thing to notice here is that doing the initial key handshake involves 1024-bit RSA or DSA public keys, typically, whereas the number you are quoting is the streaming rate for doing 56/128-bit symmetric encryption via DES, 3DES, or AES. The difference in workload between the initial public-key crypto used to set up a temporary session key as a shared secret, and the workload for doing the subsequent symmetric crypto using this session key is huge.
If you want to understand the difference, try running "openssl speed" on your favorite machine. A ~ 1GHz Intel box can do about 120 1024-bit RSA keys per second; about 20 2048-bit RSA keys per second; or 3.3 4096-bit RSA keys per second. By contrast, it can stream DES at 20MB/s or AES-128 at about 17MB/s.
Mission: Possible. (cue background music)
Your task, should you choose to accept it, is to write your own init program which runs on top of a Linux kernel without using any of the GNU userland utilities or GNU libc.
Nicely put-- where's the "+1 tasty sarcasm" mod when you need it?
That's a good summary, thanks.
n /kern_clock.c
/* ... ]
Of course, this sort of attack has been known for a while, and it's not just OS X which is mostly immune to attempts by a process to yield the CPU just before a tick to avoid having the usage assigned to the process-- if you check the source code in FreeBSD, for example, in:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ker
----added to keep the comment from wrapping onto the URL----
* Clock handling routines.
*
* This code is written to operate with two timers that run independently of
* each other.
*
* The main timer, running hz times per second, is used to trigger interval
* timers, timeouts and rescheduling as needed.
*
* The second timer handles kernel and user profiling,
* and does resource use estimation. If the second timer is programmable,
* it is randomized to avoid aliasing between the two clocks. For example,
* the randomization prevents an adversary from always giving up the cpu
* just before its quantum expires. Otherwise, it would never accumulate
* cpu ticks. The mean frequency of the second timer is stathz.
[
Good question. :-)
The former tends to mean what is doable in theory or in practice, but may not correspond to any actual realistic situation. For example, if you stuff nothing but data down the PCI (AGP, PCIe, whatever) bus, you get a rate which is about the bandwidth of the underlying bus, but in reality, you have to do some setup and so forth (ie, configure the target address and size for a DMA transfer) before blasting data bits, and other PCI devices also get to get some bus cycles, so the actually obtainable data rate tends to be about only 90% of the max bandwidth of the bus in practice.
This tends to be applicable to a wide range of things, from ethernet/networking load capacities, to disk I/O performance, to video card framerates, etc....
Agreed, but it has nothing to do with vertical syncing.
What's happening on the Mac is that almost all window draws are done in a double-buffered context, so that any changes first are drawn offscreen, and then only the changed regions actually get blitted into video memory. The classic example of the problem you're seeing on windows is something like a window showing "Downloading at 170K/s", where the entire string keeps flickering because they redraw the whole line on screen, rather than just updating the number if it changes. The Mac approach uses more memory, but it means that you can switch back and forth between two windows which overlay each other and have the obscured sections get immediately blitted rather than needing the app to redraw the obscured parts.
This is used elsewhere, too-- such as in X11 called the "Damage extension"....
I doubt it's anything personal; some spammers grovel through WHOIS records and simply joe-job random domains and set the bounce address to postmaster@ or the listed WHOIS contacts-- and, of course, they also do the traditional scraping of email addys from websites, mailing lists, etc. Setting up SPF records and doing SPF checking does quite a bit to reduce the backscatter from forged email which gets bounced back to you.
Once or twice in drastic cases, I've actually had to use HELO-level checking to reject all mail coming from .ru and .cn domains during a heavy run of forged spam bouncing back to a domain I run, but only for a few days until the domains in question started gaining some clue about SPF.
However, if you reject email delivered to postmaster@your_domain, then your mail system isn't configured right, and you should expect to be blacklisted.
This is a good thing to notice and be aware of, but it is fairly normal for ISPs to not put a firewall in place between business-class service at the colo level to verify source addresses and filter out spoofed traffic from other netblocks owned by that ISP.
The trick for this to be useable for anything beyond a mildly cloaked DoS is that you either have to use source routing so that the answers come back to you, or you have to be close enough to the subnet being spoofed that you can fiddle with the router which sends it to that subnet or to yours.
Think of ARP spoofing, think of using ICMP router redirects, think of RIP or BGP advertisements, think of spoofing a VLAN header and waving the magic wand at the switch and claim that your connection is really a trunk port (and then repeat with the ARP spoofing :-).
(hums a banal Woody Guthrie tune)
"This route is YOUR route, this route is MY route, this route is OUR route..."
In Cisco ISO-speak, to do such checking is called "Reverse Path Forwarding". See RFCs 1812 and 2267 and perhaps you can give your ISP a security clue, or take advantage of the opportunities to experiment, depending. :-)
http://www.cisco.com/univercd/cc/td/doc/product/so ftware/ios111/cc111/uni_rpf.htm
You're right about publicly published APIs defined in something like a header file do not qualify as grounds for copyright infringement, at least here in the USA (YMMV may vary elsewhere).
On the other hand, nothing requires a vendor to release their private header files to the world, and those may well be copyrighted and marked as "proprietary trade secret information", although that's obviously not applicable to header files under the LGPL. :-)
Of course it gets unclear what happens if header files contain inline functions (whoever puts code to header file should be shot at noon:) but function signatures or class definitions aren't copyrightable code.You're making a broad generalization here about something that may not be quite so simple, as, if it comes down to a real-world case, then the judge is the one who decides what merits copyright protection and what doesn't.
PS: yes, I missed the slash in my trailing < quote > tags.
PPS: and yep, i used preview, but i thought the reverse-indented quoting looked kinda neat so I decided to leave it as-is. Whoop whoop!
So, let's consider the costs for a BB and an iPhone over one and two years, going with your #'s:
For one year:
BB: 12 months * $80/month plan + 99 = $1059
iPhone: 12 * 80 + 599 = $1559
Result: BB costs 2/3rds as much as an iPhone
For two years:
BB: 24 months * $80/month plan + 99 = $2059
iPhone: 24 * 80 + 599 = $2559
Result: BB costs 4/5ths as much as an iPhone
What this comes down to is, would you choose to pay an extra 25% over the cost of a BB to have an iPhone instead?
There's a difference between permitting "reverse engineering" and requiring a vendor to publish proprietary specs/APIs/hardware interfaces. Can't you just rip the original CDs to MP3 and go on with life, rather than getting all hot and bothered that your cell phone/Rio/Creative ZEN/whatever can't play AAC? :-)
Anyway, note that reverse engineering to make a system functional is allowed here in the US (even with the DMCA), which means that Linux DVD *players* are OK, but DVD *copiers* or software which can copy a DVD seem to cross the line.
With due respect, I have to disagree. If a project or vendor takes security seriously, they'll design the software so that it has zero security bugs.
Almost nobody delivers this for popular commercial software like Windows, Office, etc, but that's more because the people paying for such software seem to not care about security at all, or value new features, convenience, and speed much more than they do security or reliability.
However, people designing control systems for airplanes, hospital medical equipment used in lifesaving situations, and so forth, actually do a fair job of delivering software which has zero security issues. This level of quality isn't undoable for more widely used general-purpose software-- some of DJB's software has close to a perfect security record, for example, but it is rare to find software which was designed from the start with the assumption that no security holes are acceptable.
Especially in the PC world, it's common to find software which is significantly broken in the initial release and needs to be patched before it is even feature-complete, much less close to being "bug free" or "secure"....
I certainly agree with you, here. I just have a hard time squaring your concern about this matter with your .sig:
Would it help if I mentioned that I like Fox News and agree with most of what Sean Hannity says?Maybe we should make sure that children avoid watching Fox? :-)
So? It seems to me that we're all going to experience Death sooner or later regardless-- nobody lives forever. It also seems to me that the quality of the life people live ought to be a lot more important than simply extending the duration, especially people in the terminal stages of cancer or whatnot....
There were email systems which predated SMTP using TCP/IP transport, such as MMDF over something like UUCP, or DEC's Mail (ie, http://en.wikipedia.org/wiki/Mail-11) which ran either local mode only or over DECnet, using the "::" syntax for explicit hop-to-hop relaying.
These systems had some advantages, in that you typically could only send email to hosts which you had an explicitly configured topology set up for you by an admin. This predated the notion of spam or the notion that people could set up and use a network or cluster of machines without having someone clueful around to supervise and fix problems. Later on, they acquired the notion of Bitnet and ARPA network gateways to transfer mail to foreign systems....
* reliable delivery (Is it there yet?)
The SMTP procotol provides for reliable delivery, but MTAs which fail to adhere to the standard can lose email.
* reliable authentication (Is the sender whom they claim to be?)This is a moderately hard problem to solve, but it's more an issue with most users being unable or unwilling to use things like PGP/GnuPGP or S/MIME.
* timely delivery (Preferably under 10 minutes to any destination, or the original sender is notified, preferably NOT via email)The overwhelming majority of email is delivered in under 10 minutes, but if someone's mailserver or Internet connection is down, then mail ain't going to be delivered until the problem gets rectified. I just checked my mailserver logs and out of the 500 emails delivered today, the average delay was about 5 seconds, and the longest delay was 111 seconds.
It's actually a per-user preference.
Click on Preferences from the top nav bar, click on Comments, look down for "Comment Post Mode" to change the default mode that your posts are sent out as. And yes, if you use normal HTML tags from the "allowed" list, then your browser will typically interpret those even within posts sent as "Plain Old Text", but might screw up things like greater-than and less-than signs, too.
They are-- section 5 of the FTC act, aka 15 U.S.C. 45(a)(2):
s c_sec_15_00000045----000-.html ...I think the penalties go up to $10,000 per incident. The FTC has more documents about false advertising here:
d v.shtm
http://www.law.cornell.edu/uscode/html/uscode15/u
http://www.ftc.gov/bcp/menus/resources/guidance/a