Even though the "Service Agreement" says no servers, as long as I keep the traffic down, they don't have a problem (I even discussed this with them). HTTP incoming, https, ssh, ftp. SMTP incoming and outgoing.
All works.
I tried Bell Sympatico DSL service -- but they block *incoming* port 25. How dumb is that? I couldn't even receive emails anymore!
Yes, they cancelled the free news service. Which I miss, and complained about. And I don't really need the "extras". But it does work.
Let's say that the data is encrypted. To be secure, keys must be negotiated with EACH of the sending machines. The crypto had better be simple... and useless.
Let's say a single key is used... the key has to be exchanged with the server. Either the complete list of servers is known, or a key exchange can be initiated. If the complete list of servers is known, and they all go away, the transfer cannot complete. Useless.
So, a key exchange can be initiated. Which means that the keys themselves are insecure. Useless.
So. encrypting the data is useless. A similar argument can be made for the exchanges of the machines in the mesh.
Remember P2P in the BitTorrent context means many sources of the same content.
Now, the "encryption" has to be (only) good enough to make it better (cheaper) to actually route the packets rather than figure out that they should be "throttled". And this must hold assuming that the "man in the middle" (aka ISP), has a record of the ENTIRE set of transactions.
Very VERY difficult.
(and all of this assumes that the ISP wants to "throttle" and not just control this kind of traffic -- see my other post on this topic).
But... traffic flowing OUTSIDE of the ISP costs the ISP more money. Even if a file is available WITHIN the ISP, the P2P application may well decide to do something silly -- like download it from Russia. Which ends up costing the ISP a LOT more money.
The problem is current P2P applications. They do not (generally) discriminate peers based on IP network addresses. Just "ping time" or somesuch measure. The ISP then uses a shaping appliance: NOT to "throttle" P2P traffic, but to connect up P2P users and keep them INSIDE the ISP network as much as possible.
This has the result of (1) possibly improving the users speed, and (2) saving the ISP money.
"Encrypting" the connection would be a very BAD idea, as the traffic can no longer be controlled this way. A better approach would be to create a "P2P Mesh Discovery Protocol" as an official RFC.
As long as the ISP doesn't have to look at the data, they will be happy to provide such "P2P" acceleration services.
(As usual, I may be completely full of it, and YMMV, etc.)
Ratboy
PS. Rogers didn't block BitTorrent -- not for me, anyway. And eMule also works just fine.
If you need Photoshop, or are happy using Photoshop, then use it. On Mac, or Windows, or whatever platform it runs on.
If, as the article mentions, Photoshop is a Platform, and not just a piece of software, you really don't have a choice.
Maybe it will be released for Linux, maybe not. It almost certainly won't be released for SGI IRIX, or SUN Solaris.
That's pretty much all there is to that discussion.
===
Except that it leads to another question -- Why is Photoshop a platform OUTSIDE the limited area of Graphics Arts? In other words, why do a lot of people, who otherwise shouldn't care, use it?
For example, MS Excel is comparable with (say) GNU Gnumeric. I can't swear to the LATEST Excel version, but previous versions did really bad stats calculations. So, I used Gnumeric. However, MOST PEOPLE DON'T CARE ABOUT STATS! Exel is "good enough". People who did care, switched. In a similar vein, GIMP should be "good enough" but it isn't. Since Photoshop is quite expensive, more people should be happy with the "good enough" GIMP.
I don't do CMYK separations. I print pictures, and then forward stuff electronically to a publisher. The publisher can take care of it from there. She knows what to do (including "Photoshop").
There IS a reason that Photoshop is popular. "Photoshop" has become a common verb. There is an underground of "Photoshop" knowledge. Graft a head onto this picture &etc. And it must be easy to bootleg Photoshop. Otherwise it sure is an expensive way to "goatse" your photographs.
An interesting way to make money -- encourage bootlegging to provide a base, and then charge a fortune from the professionals.
The "problem" is the concept of a COW page (copy on write). Coupled with the semantics of mmap().
In a nutshell: I can use mmap() to map/dev/zero into memory, for (pretty much) as big as I want. 200MB? Its now mine.
I can have a pointer to this memory.
The problem? The memory doesn't exist. What I have is a pointer, and a guarantee that enough backing store exists to satisfy it.
If I read through that pointer, I will see zeros. It *is*/dev/zero after all. However, I can write into the memory. If I write something, the page that is changed is copied and replaced; taking memory AT THAT TIME. Sparsely.
The mmap() call can map a file (backing store) and allow data to be shared. Memory does not need to be used until the data is read (or written). And this time, the backing store doesn't even need swap (because the file is the backing store).
All of which means non-changeable may be altered. Changeable may be non-existent or shared. Try to teach that to your DG tools.
A page of code that is shared - may becomes a page of code that is private. A page of data that is unwritten doesn't have to exist. Even if it is read! A page of data that is written may STILL be shared.
"ps" and the other tools could walk through typical process maps, counting up pages, and figuring out what each was for, but that may be a bit too intensive. The pages aren't "cross referenced" for that purpose. Besides, the page could be COWd, and then swapped. Should THAT count against the memory of the application? Maybe, maybe not.
So "ps" by default gives you an idea of the "big picture" for each process.
Let's see if we can apply some property rights here...
Verizon (or ANYONE) is not entitled, authorized, or any such thing to dig in MY property. Whether to lay copper, fibre, or dead bodies.
The GOVERNMENT gives the right to do so. But there are some rules. Rules that I (we) impose. If the government has allowed such action (more accurately, has FORCED it), we am entitled to some benefit:
Specifically, access to the property or service at reasonable rates, with reasonable sharing.
Of course "reasonable rates" are debatable; as is "reasonable sharing".
It's not "their" pipe -- it's "our" pipe.
When cable was rolled out, it was rolled out on the understanding that cable TV was to be provided. Was an alternate TV network contemplated when the fibre was rolled out? If it was, then ok; if not, we need a PUBLIC debate.
Nothing against Verizon (or any other public utility), but that IS the rule. And if anyone gives me a hard time about, I'll backhoe my property. Sue me already.
As a final observation: Let's get into this century, already. I don't see the sewage removal provider making a play for Gas delivery. I don't see the Gas provider (delivery only) making a play for water delivery. They kind of stick to their own turf.
But the "data" services are coallescing. Voice, TV, Internet -- its all data. Reasonably, we expect that NEW pipes would treat it the same. If you close your eyes really tight, and pull back 20 years, then, yeah, its different. Which gave rise to "Cable TV" as separate from "Phone".
Now I expect a single bundle of fibre to a home and I expect it to carry ALL the data equally. A separate "bandwidth" supplier distinct from purposing.
As an example: if you have a home heated by a Gas furnace, and a Gas BBQ, and a Gas stove, would you really expect two or three different bills? Of course not, a single bill each month suffices.
I want a single "data" bill every month, that combines "TV", "Phone", "Internet", "VOD" carrier fees. I may have a separate accounting for "VOD movies", "POTS integration", "HBO access".
I advocate complete separation of the cost of maintaining the "plumbing" and "delivering" the data from the data itself. The Gas company here (Enbridge) can do, so I expect the fibre suppliers to be able to do it as well.
This is interesting, because you are using "anti-OOP" thinking here. What you are doing is "foo" -- in other words, you are NOT thinking about WHAT you are doing, but are thinking (in great detail), about the thing you are doing it to. onst ReallyComplexDataStructure& arg1, or "const char *"
Stop it.
If you can define a sensible operation, that operation should apply to as many compliant "types" as possible. It was hard to get it right the first time, no? So why invent it again? The idea is to have behavioural pre-conditions. For example: something that can be sorted MUST BE ORDERABLE. If *that* holds true, then this is how to sort. In turn: For something to be orderable it must support the LESS THAN and the EQUAL TO relation.
I am not interested in the TYPE (in the sense of "integer" vs. "float" vs. "character"). I AM interested in what holds true and what can be done.
Maybe Java needs to take a page out of Smalltalks book. Smalltalk really has very few errors: "DoesNotUnderstand" would be the catchall. But the "debugger" is tied right in, and you get an immediate traceback. The compiler is tied to the browser, and development is very interactive.
I am very aware of the issues. No, I do NOT like "UDI" (and I am very familiar with it, thanks).
Solaris has a well defined DDI, and ABI. It uses symbol versioning, and has very good binary application support. It ALSO runs Intel x86 binaries.
Windows has a defined DDI, and a (arguably looser) defined ABI. It does not use symbol versioning, but relies on Microsoft (and beta) testing).
Linux has a well defined ABI, a reasonably defined GLIBC interface and loose C++ library interfaces. No DDI at all.
I will let you slot in OS X into this picture yourself (I am not a fan or supporter of Apple, for other reasons).
For desktop deployment of general applications, my own preference is (in order); Solaris, Windows, Linux.
For custom (low volume) applications: Linux, Solaris, Windows.
For server applications: Solaris, Linux, Windows (especially now that Solaris has dtrace and containers).
When I refer to "Linux" above, I am actually refering to a distribution. The distributions I recommend clients code to are Redhat Enterprise, and SUSE (server *or* desktop deployment). It is possible to deploy a "Linux Binary LSB compliant" application across a wider range of targets -- but you need to apply a lot of library isolation, and control.
Ratboy
Re:Dynamic typing
on
Beyond Java
·
· Score: 2, Informative
What "dynamic typing" lets you do is forget about data types.
Then, code can be restructured to REDUCE the amount of code that is necessary. Sort of what the C++ template system is supposed to do.
Source code reduction is a very good thing.
With OOP programming, the idea is that an "object" encapsulates "dynamic type" -- not by type, but by interface. Generally, it is preferred to be able to inspect the possible behaviour at run-time (C++ RTTI).
This means that generic code can be written, that separates out the thing being done from a particular "type-based" implementation.
An example is in order: If I have a "type" that represents ordered values, it can have a "less than" and "equal to". Knowing ONLY that, I can derive "greater than" as "not (less than or equal to)".
I need no further information. Specifically, my "greater than" will now work on ANY ordered type: integer, large integer, float, date, string. And here it is, in psuedo-code (modified to look non-OOP):
Now, it may be a NASTY job trying to execute this "efficiently" (or not, efficient language interpretation is not a specialization of mine). But the definition is correct. And can be reused easily (if the language is "correct" (by some definition) the reuse is automatic.
Languages that implement this are THE most productive: Smalltalk is the prime example. I still prefer LISP, but YMMV. This kind of thing should be easy, and automatic.
If a language is "OOP" there should be no way of peeking under the covers for an implementation. This is important because it allows the REPLACEMENT of an implementation; potentially at runtime. There is an entire class of bugs that are easily eliminated by this.
Contemplate the following definition of factorial (and it may be wrong, I am just typing this in):
unsigned int factorial(unsigned int n) {
if (n Ratboy
Yes, I don't understand why symbol versioning in Linux doesn't follow the Solaris model. So goes life, I guess. What I do is pick specific distribution, and use it as a base (last time it was Redhat 9). And its GNOME, baby (for me). Maybe I have been lucky with my projects.
---- Back to DRM.
We can use "wrapped keys". The implementation of the crypto needs to be known. The generation and encryption of keys is centralised. The wrapped key may then passed around through software that may be comprimised. We then need to secure the central key generator, because that is our vulnerability. We have to "trust" something... This component can have a hash generated, and compared to known values (has been done that way), etc. Eventually, leads to a "secure hardware key manager" that is the trusted element. Generally, the entire kernel is "trusted" from the application standpoint.
How do I reconcile this with Open Source? Any driver can still be modified -- but if it needs to participate in a secure operation, it must be signed. Thats all. Applications do NOT need to request driver security.
I contract for a living. Device drivers are one of the things that I do. And, believe it or not, each vendor does abstract. Even for Windows.
Also, the "line in the sand" issue. The original poster was talking about C++ library interdependencies. Two different versions of the same library, for instance, one used by the application, the other by something the application uses. Etc.
And where do you want to draw the line? The original poster was lamenting that a binary only C++ application that would work fine on one distribution may fail on another, or (almost randomly) fail if other software had been loaded. And sure, he is right. I just pointed out that the line IS the application to OS barrier, and to ensure that all application parts are correctly supplied, presuming that you want to distribute a binary only application.
And for Linux, the boundary between the OS and the application is the "syscall" interface. IT IS NOT GLIBC.
And the boundary between a driver and the OS -- Linux doesn't HAVE a DDI.
Now, I will make a suggestion. If you want a vendor that supplies C++, OS, libraries and drivers, *with* a DDI, go to Microsoft.
If you want the same with a Unix flair, able to execute "Linux Binaries", go to SUN and use Solaris 10.
I don't complain that people don't use Linux. Why on Earth should I care? Windows makes me more money, anyway.
I am writing from the perspective of a developer.
Yes, the application installer will be a GUI for you. Have you ever seen a modern RPM installer?
As to my driver contention -- have you seen the nVidea and VmWare drivers? They "Just Work". My contention was that AT LEAST partial source is needed under Linux to achieve this end. My contention is that if you are unwilling to do this, go with Windows!
ELF supports symbol versioning. And that's what is supposed to take care of these issues. That's what Solaris uses.
Why isn't it used? I really don't know (I am an ex SUN staff engineer -- can't really comment on Linux or GNU designs). ELF is a proven technology, for projects in the million+ LOC range.
However, what part of private libraries wasn't clear? That would include the application support libraries. Your versions. Indeed, statically link the thing -- its a binary. I really don't see the big deal here.
This controls "accidental collisions" completely. Now, if you WANT to use dynamic libraries, and want to control versioning, and DON'T want to use the native approach to it, and are trying to develop a huge application (which seems to be your position) -- use separate process spaces and dynamically load what you need into each one. Again, no collisions. And no big deal.
The ELF loader is trying to build an image for you, with everything specified, and trys to reuse already loaded bits. And that's ALL it does. It really is the job of the application developer to deploy the application correctly.
----
As to the "SAP" thing. The idea is that the data remains encrypted until the very last possible moment. As an example, the audio driver (signed) generates a public/private key pair, and hands the public key to the application, which then uses that to encrypt the data which only the audio driver can decrypt. Of course, the audio driver can't be (pre-load) tampered with because it would then fail its signing (where the signing private key is not available).
That's the thing in a nutshell. The "trusted" component is the key management -- specifically the secret driver signing key (for this particular embodyment (sp?)).
So, go out and get a (or make a key pair). Modify the Linux loader to allow signing by wrapping the driver object.
That would be it. Total Linux kernel change -- minor. Of course, getting that into the mainline may be difficult (although there is NOTHING in there that isn't open source). There is still a problem, though -- the kernel debugger. There would have to be a way to disable debugging on a signed module. Which there isn't (because of virtualization technology). Until something is put into the processor core itself. Still, DRM support itself (at least effective against most developers and all users) is easy.
Anyway, Linux is HEAVILY used in "DRM" environments -- embedded systems (video), etc. Arguably, more so than Windows. And, on a consumer OS level, it is EASIER to incorporate DRM into Linux.
Feel free to use the design outlined here. Nothing that isn't SOP in the security world. The hardest steps are to (1) convince people that a "signed driver" is a good thing and (2) to get a key or circuit embedded on the processor. (1) is done, thanks to Microsoft, and (2) is done, thanks to IBM Thinkpads. Keep that private signing key secret, and tada! DRM.
Driver Support: not centralized, and easy to do. AS LONG AS THE DRIVER IS DISTRIBUTED IN SOURCE. Binary distribution can cover a few of the kernels out there. Lets take a look at nVidia and VmWare as binary drivers, with a source supplied front-end. They "Just Work". A completely binary driver IS problematic.
And this is one of the "features" of Linux vs. Windows. If you WANT "binary drivers that Just Work", go with Windows.
C++ support: it does work. No, a single binary MAY NOT WORK. *Unless* you also distribute the needed libraries. Nothing AT ALL is preventing you from doing that. These libraries can and should even be installed privately for your binary-only application. Someone updates the system library? Doesn't affect you.
No easy install/uninstall: Sounds like you are carping about the Linux systems themselves. As far as your BINARY APPLICATION goes -- keep it in a single directory (tree). Uninstall? Remove the tree. You want to get fancy? Combine that with bundling into a RPM.
No credible DRM support: Say What? "DRM support" is a problem of the Media Supplier. Name a "DRM" format that is popular that Linux doesn't support... DVD CSS. And how is this managed? mplayer? Oh, so there IS support.
As to your application... Linux offers filesystem encryption (3des, etc.). Other crypto functionality. SSL, ssh, gpg. Locked memory.
Let me outline a possible "DRM" solution for you (assuming you ARE a Media Supplier). Sell someone a physical DVD with data on it. Encrypted with 3DES or AES 128/256. Key not provided, but a media reference tag.
Application has a "root" component (for locking), or uses Role Based security (not so common). Application uses SSL (or ssh) to establish a link to your server. Coughs up user name, invoice number, and media tag (over the encrypted link). Server verifies, and coughs up the decryption key. Decryption key tossed into locked memory (thus the root requirement). Decryption key used to decrypt Media.
Other implementations are, of course, possible. How is the digital data protected after it is decrypted? There are methods -- but these are not supported in ANY current OS. (not Linux, not Windows, not Solaris). As to basic DRM? Linux is just as useful as anything else.
Why? I don't want to learn "alphabet soup". If I need to write a simple GUI application, I need it to STAY SIMPLE. I don't have the time to argue with C++. Face it, even with Unix most of my stuff is written in sh, awk, perl. NOT IN C or C++.
I don't even want to here about VB.NET! Give me old fashioned VB (5 or 6 - I use 5). Kind of like Perl for Windows.
Yes, I know about the "Windows Scripting Host". I *could* write in JScript (I don't know if VBScript is installed on my Windows). Again, VB is easier. And I push a button, an INSTALLER is born, and I can distribute my script.
So why the negativeness? Because its BASIC? Because it works? Because it targets WinNT, 95, 98..XP? Because its quick? Because people actually LIKE it?
When I do Windows dev, I generally use the Windows tools "cross" on a Linux x86 platform with Wine.
No, I haven't tried the IDE (not my speed), but CL.EXE, LINK.EXE, etc. work just fine. And you can run them straight from the command line (after registering the EXE executable type). Which means that they can be run from GNU make and can participate in AUTOCONF.
I am a Rogers Broadband customer. Rogers has, in the last year, set a data cap for my digital data service. Specifically, Rogers gives me 60GB per month, upload and download combined. I pay $40CDN per month for the service.
Now I finally have a way to compute the value of such things as this Warner P2P offering.
We need a little bit more data, though. Specifically, how big is a DVD quality movie? Between 600MB and 1.4GB for an MPEG encoded video of sufficient quality to (subjectively) look good on my big TV. 600MB for an animation, 1.4GB for a feature movie. Lets "split the difference" and call it 1GB.
Which means I can download 60 movies per month for $40. Each movie will cost me 67 cents to download.
But the P2P (Peer to Peer) model only works if I upload the material as well. To one (or more) clients. Note that my cap applies to uploads as well. I am going to assume a 1:1 ratio for down to uploads - which means my data pipe price is doubled. Specifically, to $1.33 per movie.
There is also a cost associated with having material on the hard disk for servicing uploads. I know the cost of on-line storage. My average price is now $2 per gigabyte (for my drives in service), and I replace drives every 2 years. Which means $1 per movie per year. If I assume data retension for a year (got to fill this in with something. and there has to be client retension to make P2P work!), this adds a buck, bringing my cost to $2.33.
Would I spend $2.33 to download a movie? Rental at BlockBuster average $3.50 (ish) per movie. One buck more. Which is then what the content is worth to me. Without DRM, unlimited personal use: the price of the DVD minus the above costs, minus a factor related to the time it takes to actually download/upload (because my Internet connection is tied up... and its a nuisance). I figure a MINIMUM of 5 bucks.
So, "Unencumbered DVD quality downloads using our P2P, at 30% under store DVD price" is the beginning of the play for me.
I want to comment on some of the features you list:
"New printer technology (way beyond postscript)"
This is interesting. What could be "way beyond Postscript"? Postscript is a general purpose language, with rendering support. It has even been extended into a GUI (although that is irrelevant from the perspective of printing). By utilizing a common language for print rendering, different vendor OSs and systems can actually share printers. The reference implementation of Postscript is now (arguably) Ghostscript, which is Open Source. Postscript is also behind PDF technology.
If there is a new rendering technology, how will it be incorporated into heterogenous network?
"Support for user mode drivers"
Is this a good thing? I know that there have been attempts at providing "user mode drivers" to Linux, and other OSs, but that is a REALLY BAD thing to do wrt security. Transitions from less trusted code to more trusted code are ok, because the more trusted code can check its inputs. The reverse transition is not ok -- simply because the code is less trusted.
Of course the "user mode driver" may require signing, but then why not test it and put it back into kernel mode? The only other reason I can see for "user mode drivers" is that you want the driver code and data to participate in standard OS semantics (scheduling, swapping, etc.). Which may be a good reason to do it. But the security implications are immense: maybe front layer drivers only, that cannot do anything with the OS core or data, and where data only flows "user->user driver->kernel" -- you get the idea.
Still, I was under the impression that Windows was a micro-kernel (in some sense), which is supposed to eliminate the need for this hack.
"Application level audio control"
Can you elaborate on this? I was under the impression that that was ALREADY a feature (or are you referring to OS control on the application audio, which is more interesting - specifically, the ability to route the audio output from an application to another application which can provide filtering: say, low-pass. Of course, this provides a security hole for the media, and so I doubt that this will be implemented).
The patent protects the patent owner EVEN if you never intend to sell the device. The monopoly granted is (almost) absolute. Government is exempt, and there are certain other minor exemptions. But, outside of those, the patent holder can tell you to cease and desist.
"They pay talent scouts and agents to find artists they think you'll want to listen to. They buy/build/lease a building to use as a recording studio, build top-quality sets, buy high-end equipment, hire professionals to operate and maintain the equipment and buildings, often pay the artists up front, pay for the utilities used during production, pay other professionals to edit/remaster the tracks, pay artists to design the cover and disc art, and pay for the manufacture of the discs, cases, and covers. Then they pay salesmen to go out and find distributors for the albums."
The RIAA started by standardizing the equalization of records (too much bass, the needle jumps out of the groove... etc.). They now act as agents for labels and artists (copyright holders).
The RIAA doesn't engage in or pay for any of the activities you listed. Sorry to "burst your bubble".
The Artist pays for these activities. Either the Artist or the Label engages in the activities.
One point needs clarification: "often pay the artists up front". Yes, Labels do often front money to the Artist. However, that money is subtracted from the gross; as are all other production expenses.
Generally this (masquerading) is a problem with NFS. On a small LAN this isn't much of a big deal.
Several ways to solve the problem. First, UID and GID can be centrally controlled on a LAN by use of NIS. Still, if the machine is under the control of someone else, a forged UID/GID may be presented.
This can be controlled by the NFS server using "root squashing" or "all squash".
Both of these options "distrust" the UID/GID. In the case of root squash, root UID (0) is remapped to "nobody". This is a good thing on a LAN, because root file priviledge is contained. However, the attacker can obtain someone elses UID. Sensitive material should be encrypted. "All squash" option remaps all UIDs to "nobody" and is typically deployed for read-only shares, or "bulletin board" directories.
The security of your LAN is only as good as the security of the machines making up that LAN, anyway.
Slashdot Mirror
I use Rogers.
Even though the "Service Agreement" says no servers, as long as I keep the traffic down, they don't have a problem (I even discussed this with them). HTTP incoming, https, ssh, ftp. SMTP incoming and outgoing.
All works.
I tried Bell Sympatico DSL service -- but they block *incoming* port 25. How dumb is that? I couldn't even receive emails anymore!
Yes, they cancelled the free news service. Which I miss, and complained about. And I don't really need the "extras". But it does work.
YMMV
Ratboy.
Encrypt WHAT?
Let's say that the data is encrypted. To be secure, keys must be negotiated with EACH of the sending machines. The crypto had better be simple... and useless.
Let's say a single key is used... the key has to be exchanged with the server. Either the complete list of servers is known, or a key exchange can be initiated. If the complete list of servers is known, and they all go away, the transfer cannot complete. Useless.
So, a key exchange can be initiated. Which means that the keys themselves are insecure. Useless.
So. encrypting the data is useless. A similar argument can be made for the exchanges of the machines in the mesh.
Remember P2P in the BitTorrent context means many sources of the same content.
Now, the "encryption" has to be (only) good enough to make it better (cheaper) to actually route the packets rather than figure out that they should be "throttled". And this must hold assuming that the "man in the middle" (aka ISP), has a record of the ENTIRE set of transactions.
Very VERY difficult.
(and all of this assumes that the ISP wants to "throttle" and not just control this kind of traffic -- see my other post on this topic).
Ratboy.
is happy customers, and a good profit.
And customers want to do P2P.
But... traffic flowing OUTSIDE of the ISP costs the ISP more money. Even if a file is available WITHIN the ISP, the P2P application may well decide to do something silly -- like download it from Russia. Which ends up costing the ISP a LOT more money.
The problem is current P2P applications. They do not (generally) discriminate peers based on IP network addresses. Just "ping time" or somesuch measure. The ISP then uses a shaping appliance: NOT to "throttle" P2P traffic, but to connect up P2P users and keep them INSIDE the ISP network as much as possible.
This has the result of (1) possibly improving the users speed, and (2) saving the ISP money.
"Encrypting" the connection would be a very BAD idea, as the traffic can no longer be controlled this way. A better approach would be to create a "P2P Mesh Discovery Protocol" as an official RFC.
As long as the ISP doesn't have to look at the data, they will be happy to provide such "P2P" acceleration services.
(As usual, I may be completely full of it, and YMMV, etc.)
Ratboy
PS. Rogers didn't block BitTorrent -- not for me, anyway. And eMule also works just fine.
If you need Photoshop, or are happy using Photoshop, then use it. On Mac, or Windows, or whatever platform it runs on.
If, as the article mentions, Photoshop is a Platform, and not just a piece of software, you really don't have a choice.
Maybe it will be released for Linux, maybe not. It almost certainly won't be released for SGI IRIX, or SUN Solaris.
That's pretty much all there is to that discussion.
===
Except that it leads to another question -- Why is Photoshop a platform OUTSIDE the limited area of Graphics Arts? In other words, why do a lot of people, who otherwise shouldn't care, use it?
For example, MS Excel is comparable with (say) GNU Gnumeric. I can't swear to the LATEST Excel version, but previous versions did really bad stats calculations. So, I used Gnumeric. However, MOST PEOPLE DON'T CARE ABOUT STATS! Exel is "good enough". People who did care, switched. In a similar vein, GIMP should be "good enough" but it isn't. Since Photoshop is quite expensive, more people should be happy with the "good enough" GIMP.
I don't do CMYK separations. I print pictures, and then forward stuff electronically to a publisher. The publisher can take care of it from there. She knows what to do (including "Photoshop").
There IS a reason that Photoshop is popular. "Photoshop" has become a common verb. There is an underground of "Photoshop" knowledge. Graft a head onto this picture &etc. And it must be easy to bootleg Photoshop. Otherwise it sure is an expensive way to "goatse" your photographs.
An interesting way to make money -- encourage bootlegging to provide a base, and then charge a fortune from the professionals.
Ratboy
The "problem" is the concept of a COW page (copy on write). Coupled with the semantics of mmap().
/dev/zero into memory, for (pretty much) as big as I want. 200MB? Its now mine.
/dev/zero after all. However, I can write into the memory. If I write something, the page that is changed is copied and replaced; taking memory AT THAT TIME. Sparsely.
In a nutshell: I can use mmap() to map
I can have a pointer to this memory.
The problem? The memory doesn't exist. What I have is a pointer, and a guarantee that enough backing store exists to satisfy it.
If I read through that pointer, I will see zeros. It *is*
The mmap() call can map a file (backing store) and allow data to be shared. Memory does not need to be used until the data is read (or written). And this time, the backing store doesn't even need swap (because the file is the backing store).
All of which means non-changeable may be altered. Changeable may be non-existent or shared. Try to teach that to your DG tools.
A page of code that is shared - may becomes a page of code that is private. A page of data that is unwritten doesn't have to exist. Even if it is read! A page of data that is written may STILL be shared.
"ps" and the other tools could walk through typical process maps, counting up pages, and figuring out what each was for, but that may be a bit too intensive. The pages aren't "cross referenced" for that purpose. Besides, the page could be COWd, and then swapped. Should THAT count against the memory of the application? Maybe, maybe not.
So "ps" by default gives you an idea of the "big picture" for each process.
Ratboy
Of course it's "their" pipe. Under "my" land.
Let's see if we can apply some property rights here...
Verizon (or ANYONE) is not entitled, authorized, or any such thing to dig in MY property. Whether to lay copper, fibre, or dead bodies.
The GOVERNMENT gives the right to do so. But there are some rules. Rules that I (we) impose. If the government has allowed such action (more accurately, has FORCED it), we am entitled to some benefit:
Specifically, access to the property or service at reasonable rates, with reasonable sharing.
Of course "reasonable rates" are debatable; as is "reasonable sharing".
It's not "their" pipe -- it's "our" pipe.
When cable was rolled out, it was rolled out on the understanding that cable TV was to be provided. Was an alternate TV network contemplated when the fibre was rolled out? If it was, then ok; if not, we need a PUBLIC debate.
Nothing against Verizon (or any other public utility), but that IS the rule. And if anyone gives me a hard time about, I'll backhoe my property. Sue me already.
As a final observation: Let's get into this century, already. I don't see the sewage removal provider making a play for Gas delivery. I don't see the Gas provider (delivery only) making a play for water delivery. They kind of stick to their own turf.
But the "data" services are coallescing. Voice, TV, Internet -- its all data. Reasonably, we expect that NEW pipes would treat it the same. If you close your eyes really tight, and pull back 20 years, then, yeah, its different. Which gave rise to "Cable TV" as separate from "Phone".
Now I expect a single bundle of fibre to a home and I expect it to carry ALL the data equally. A separate "bandwidth" supplier distinct from purposing.
As an example: if you have a home heated by a Gas furnace, and a Gas BBQ, and a Gas stove, would you really expect two or three different bills? Of course not, a single bill each month suffices.
I want a single "data" bill every month, that combines "TV", "Phone", "Internet", "VOD" carrier fees. I may have a separate accounting for "VOD movies", "POTS integration", "HBO access".
I advocate complete separation of the cost of maintaining the "plumbing" and "delivering" the data from the data itself. The Gas company here (Enbridge) can do, so I expect the fibre suppliers to be able to do it as well.
Ratboy.
This is interesting, because you are using "anti-OOP" thinking here. What you are doing is "foo" -- in other words, you are NOT thinking about WHAT you are doing, but are thinking (in great detail), about the thing you are doing it to. onst ReallyComplexDataStructure& arg1, or "const char *"
Stop it.
If you can define a sensible operation, that operation should apply to as many compliant "types" as possible. It was hard to get it right the first time, no? So why invent it again? The idea is to have behavioural pre-conditions. For example: something that can be sorted MUST BE ORDERABLE. If *that* holds true, then this is how to sort. In turn: For something to be orderable it must support the LESS THAN and the EQUAL TO relation.
I am not interested in the TYPE (in the sense of "integer" vs. "float" vs. "character"). I AM interested in what holds true and what can be done.
Ratboy.
Maybe Java needs to take a page out of Smalltalks book. Smalltalk really has very few errors: "DoesNotUnderstand" would be the catchall. But the "debugger" is tied right in, and you get an immediate traceback. The compiler is tied to the browser, and development is very interactive.
Ratboy.
And why not? Ok. maybe its Ruby, and the classes aren't defined that way...
But, why isn't a "string" simply an "array of characters"?
Ratboy.
I am very aware of the issues. No, I do NOT like "UDI" (and I am very familiar with it, thanks).
Solaris has a well defined DDI, and ABI. It uses symbol versioning, and has very good binary application support.
It ALSO runs Intel x86 binaries.
Windows has a defined DDI, and a (arguably looser) defined ABI. It does not use symbol versioning, but relies on Microsoft (and beta) testing).
Linux has a well defined ABI, a reasonably defined GLIBC interface and loose C++ library interfaces. No DDI at all.
I will let you slot in OS X into this picture yourself (I am not a fan or supporter of Apple, for other reasons).
For desktop deployment of general applications, my own preference is (in order); Solaris, Windows, Linux.
For custom (low volume) applications: Linux, Solaris, Windows.
For server applications: Solaris, Linux, Windows (especially now that Solaris has dtrace and containers).
When I refer to "Linux" above, I am actually refering to a distribution. The distributions I recommend clients code to are Redhat Enterprise, and SUSE (server *or* desktop deployment). It is possible to deploy a "Linux Binary LSB compliant" application across a wider range of targets -- but you need to apply a lot of library isolation, and control.
Ratboy
What "dynamic typing" lets you do is forget about data types.
Then, code can be restructured to REDUCE the amount of code that is necessary. Sort of what the C++ template system is supposed to do.
Source code reduction is a very good thing.
With OOP programming, the idea is that an "object" encapsulates "dynamic type" -- not by type, but by interface. Generally, it is preferred to be able to inspect the possible behaviour at run-time (C++ RTTI).
This means that generic code can be written, that separates out the thing being done from a particular "type-based" implementation.
An example is in order: If I have a "type" that represents ordered values, it can have a "less than" and "equal to". Knowing ONLY that, I can derive "greater than" as "not (less than or equal to)".
I need no further information. Specifically, my "greater than" will now work on ANY ordered type: integer, large integer, float, date, string. And here it is, in psuedo-code (modified to look non-OOP):
greater_than(orderedX, orderedY)
return not(or(equal_to(orderedX, orderedY),
less_than(orderedX, orderedY)))
Now, it may be a NASTY job trying to execute this "efficiently" (or not, efficient language interpretation is not a specialization of mine). But the definition is correct. And can be reused easily (if the language is "correct" (by some definition) the reuse is automatic.
Languages that implement this are THE most productive: Smalltalk is the prime example. I still prefer LISP, but YMMV. This kind of thing should be easy, and automatic.
If a language is "OOP" there should be no way of peeking under the covers for an implementation. This is important because it allows the REPLACEMENT of an implementation; potentially at runtime. There is an entire class of bugs that are easily eliminated by this.
Contemplate the following definition of factorial (and it may be wrong, I am just typing this in):
unsigned int factorial(unsigned int n)
{
if (n
Ratboy
Yes, I don't understand why symbol versioning in Linux doesn't follow the Solaris model. So goes life, I guess. What I do is pick specific distribution, and use it as a base (last time it was Redhat 9). And its GNOME, baby (for me). Maybe I have been lucky with my projects.
----
Back to DRM.
We can use "wrapped keys". The implementation of the crypto needs to be known. The generation and encryption of keys is centralised. The wrapped key may then passed around through software that may be comprimised. We then need to secure the central key generator, because that is our vulnerability. We have to "trust" something... This component can have a hash generated, and compared to known values (has been done that way), etc. Eventually, leads to a "secure hardware key manager" that is the trusted element. Generally, the entire kernel is "trusted" from the application standpoint.
How do I reconcile this with Open Source?
Any driver can still be modified -- but if it needs to participate in a secure operation, it must be signed. Thats all. Applications do NOT need to request driver security.
I contract for a living. Device drivers are one of the things that I do. And, believe it or not, each vendor does abstract. Even for Windows.
Also, the "line in the sand" issue. The original poster was talking about C++ library interdependencies. Two different versions of the same library, for instance, one used by the application, the other by something the application uses. Etc.
And where do you want to draw the line? The original poster was lamenting that a binary only C++ application that would work fine on one distribution may fail on another, or (almost randomly) fail if other software had been loaded. And sure, he is right. I just pointed out that the line IS the application to OS barrier, and to ensure that all application parts are correctly supplied, presuming that you want to distribute a binary only application.
And for Linux, the boundary between the OS and the application is the "syscall" interface. IT IS NOT GLIBC.
And the boundary between a driver and the OS -- Linux doesn't HAVE a DDI.
Now, I will make a suggestion. If you want a vendor that supplies C++, OS, libraries and drivers, *with* a DDI, go to Microsoft.
If you want the same with a Unix flair, able to execute "Linux Binaries", go to SUN and use Solaris 10.
Ratboy
I don't complain that people don't use Linux. Why on Earth should I care? Windows makes me more money, anyway.
I am writing from the perspective of a developer.
Yes, the application installer will be a GUI for you. Have you ever seen a modern RPM installer?
As to my driver contention -- have you seen the nVidea and VmWare drivers? They "Just Work". My contention was that AT LEAST partial source is needed under Linux to achieve this end. My contention is that if you are unwilling to do this, go with Windows!
And, in future, don't ascribe bias to me.
Ratboy.
ELF supports symbol versioning. And that's what is supposed to take care of these issues. That's what Solaris uses.
Why isn't it used? I really don't know (I am an ex SUN staff engineer -- can't really comment on Linux or GNU designs). ELF is a proven technology, for projects in the million+ LOC range.
However, what part of private libraries wasn't clear? That would include the application support libraries. Your versions. Indeed, statically link the thing -- its a binary. I really don't see the big deal here.
This controls "accidental collisions" completely. Now, if you WANT to use dynamic libraries, and want to control versioning, and DON'T want to use the native approach to it, and are trying to develop a huge application (which seems to be your position) -- use separate process spaces and dynamically load what you need into each one. Again, no collisions. And no big deal.
The ELF loader is trying to build an image for you, with everything specified, and trys to reuse already loaded bits. And that's ALL it does. It really is the job of the application developer to deploy the application correctly.
----
As to the "SAP" thing. The idea is that the data remains encrypted until the very last possible moment. As an example, the audio driver (signed) generates a public/private key pair, and hands the public key to the application, which then uses that to encrypt the data which only the audio driver can decrypt. Of course, the audio driver can't be (pre-load) tampered with because it would then fail its signing (where the signing private key is not available).
That's the thing in a nutshell. The "trusted" component is the key management -- specifically the secret driver signing key (for this particular embodyment (sp?)).
So, go out and get a (or make a key pair). Modify the Linux loader to allow signing by wrapping the driver object.
That would be it. Total Linux kernel change -- minor. Of course, getting that into the mainline may be difficult (although there is NOTHING in there that isn't open source). There is still a problem, though -- the kernel debugger. There would have to be a way to disable debugging on a signed module. Which there isn't (because of virtualization technology). Until something is put into the processor core itself. Still, DRM support itself (at least effective against most developers and all users) is easy.
Anyway, Linux is HEAVILY used in "DRM" environments -- embedded systems (video), etc. Arguably, more so than Windows. And, on a consumer OS level, it is EASIER to incorporate DRM into Linux.
Feel free to use the design outlined here. Nothing that isn't SOP in the security world. The hardest steps are to (1) convince people that a "signed driver" is a good thing and (2) to get a key or circuit embedded on the processor. (1) is done, thanks to Microsoft, and (2) is done, thanks to IBM Thinkpads. Keep that private signing key secret, and tada! DRM.
Ratboy.
Just a few comments -
Driver Support: not centralized, and easy to do. AS LONG AS THE DRIVER IS DISTRIBUTED IN SOURCE. Binary distribution can cover a few of the kernels out there. Lets take a look at nVidia and VmWare as binary drivers, with a source supplied front-end. They "Just Work". A completely binary driver IS problematic.
And this is one of the "features" of Linux vs. Windows. If you WANT "binary drivers that Just Work", go with Windows.
C++ support: it does work. No, a single binary MAY NOT WORK. *Unless* you also distribute the needed libraries. Nothing AT ALL is preventing you from doing that. These libraries can and should even be installed privately for your binary-only application. Someone updates the system library? Doesn't affect you.
No easy install/uninstall: Sounds like you are carping about the Linux systems themselves. As far as your BINARY APPLICATION goes -- keep it in a single directory (tree). Uninstall? Remove the tree. You want to get fancy? Combine that with bundling into a RPM.
No credible DRM support: Say What? "DRM support" is a problem of the Media Supplier. Name a "DRM" format that is popular that Linux doesn't support... DVD CSS. And how is this managed? mplayer? Oh, so there IS support.
As to your application... Linux offers filesystem encryption (3des, etc.). Other crypto functionality. SSL, ssh, gpg. Locked memory.
Let me outline a possible "DRM" solution for you (assuming you ARE a Media Supplier). Sell someone a physical DVD with data on it. Encrypted with 3DES or AES 128/256. Key not provided, but a media reference tag.
Application has a "root" component (for locking), or uses Role Based security (not so common). Application uses SSL (or ssh) to establish a link to your server. Coughs up user name, invoice number, and media tag (over the encrypted link). Server verifies, and coughs up the decryption key. Decryption key tossed into locked memory (thus the root requirement). Decryption key used to decrypt Media.
Other implementations are, of course, possible. How is the digital data protected after it is decrypted? There are methods -- but these are not supported in ANY current OS. (not Linux, not Windows, not Solaris). As to basic DRM? Linux is just as useful as anything else.
Ratboy.
"I can't believe"
Why? I don't want to learn "alphabet soup". If I need to write a simple GUI application, I need it to STAY SIMPLE. I don't have the time to argue with C++. Face it, even with Unix most of my stuff is written in sh, awk, perl. NOT IN C or C++.
I don't even want to here about VB.NET! Give me old fashioned VB (5 or 6 - I use 5). Kind of like Perl for Windows.
Yes, I know about the "Windows Scripting Host". I *could* write in JScript (I don't know if VBScript is installed on my Windows). Again, VB is easier. And I push a button, an INSTALLER is born, and I can distribute my script.
So why the negativeness? Because its BASIC? Because it works? Because it targets WinNT, 95, 98..XP? Because its quick? Because people actually LIKE it?
Ratboy
You can probably pick up Visual Basic 5, Learning Edition for around $20 (I paid $20 CDN for it, which is around $17 US). Comes with lots of samples.
Easy to code easy stuff.
You don't need much more that that... If you *did*, I would recommend Java.
Ratboy
I can speak to Microsoft dev tools.
When I do Windows dev, I generally use the Windows tools "cross" on a Linux x86 platform with Wine.
No, I haven't tried the IDE (not my speed), but CL.EXE, LINK.EXE, etc. work just fine. And you can run them straight from the command line (after registering the EXE executable type). Which means that they can be run from GNU make and can participate in AUTOCONF.
It just works.
I am a Rogers Broadband customer. Rogers has, in the last year, set a data cap for my digital data service. Specifically, Rogers gives me 60GB per month, upload and download combined. I pay $40CDN per month for the service.
Now I finally have a way to compute the value of such things as this Warner P2P offering.
We need a little bit more data, though. Specifically, how big is a DVD quality movie? Between 600MB and 1.4GB for an MPEG encoded video of sufficient quality to (subjectively) look good on my big TV. 600MB for an animation, 1.4GB for a feature movie. Lets "split the difference" and call it 1GB.
Which means I can download 60 movies per month for $40. Each movie will cost me 67 cents to download.
But the P2P (Peer to Peer) model only works if I upload the material as well. To one (or more) clients. Note that my cap applies to uploads as well. I am going to assume a 1:1 ratio for down to uploads - which means my data pipe price is doubled. Specifically, to $1.33 per movie.
There is also a cost associated with having material on the hard disk for servicing uploads. I know the cost of on-line storage. My average price is now $2 per gigabyte (for my drives in service), and I replace drives every 2 years. Which means $1 per movie per year. If I assume data retension for a year (got to fill this in with something. and there has to be client retension to make P2P work!), this adds a buck, bringing my cost to $2.33.
Would I spend $2.33 to download a movie? Rental at BlockBuster average $3.50 (ish) per movie. One buck more. Which is then what the content is worth to me. Without DRM, unlimited personal use: the price of the DVD minus the above costs, minus a factor related to the time it takes to actually download/upload (because my Internet connection is tied up... and its a nuisance). I figure a MINIMUM of 5 bucks.
So, "Unencumbered DVD quality downloads using our P2P, at 30% under store DVD price" is the beginning of the play for me.
Ratboy
I want to comment on some of the features you list:
"New printer technology (way beyond postscript)"
This is interesting. What could be "way beyond Postscript"? Postscript is a general purpose language, with rendering support. It has even been extended into a GUI (although that is irrelevant from the perspective of printing). By utilizing a common language for print rendering, different vendor OSs and systems can actually share printers. The reference implementation of Postscript is now (arguably) Ghostscript, which is Open Source. Postscript is also behind PDF technology.
If there is a new rendering technology, how will it be incorporated into heterogenous network?
"Support for user mode drivers"
Is this a good thing? I know that there have been attempts at providing "user mode drivers" to Linux, and other OSs, but that is a REALLY BAD thing to do wrt security. Transitions from less trusted code to more trusted code are ok, because the more trusted code can check its inputs. The reverse transition is not ok -- simply because the code is less trusted.
Of course the "user mode driver" may require signing, but then why not test it and put it back into kernel mode? The only other reason I can see for "user mode drivers" is that you want the driver code and data to participate in standard OS semantics (scheduling, swapping, etc.). Which may be a good reason to do it. But the security implications are immense: maybe front layer drivers only, that cannot do anything with the OS core or data, and where data only flows "user->user driver->kernel" -- you get the idea.
Still, I was under the impression that Windows was a micro-kernel (in some sense), which is supposed to eliminate the need for this hack.
"Application level audio control"
Can you elaborate on this? I was under the impression that that was ALREADY a feature (or are you referring to OS control on the application audio, which is more interesting - specifically, the ability to route the audio output from an application to another application which can provide filtering: say, low-pass. Of course, this provides a security hole for the media, and so I doubt that this will be implemented).
The other features will be welcome.
Ratboy.
And you are WRONG!
The patent protects the patent owner EVEN if you never intend to sell the device. The monopoly granted is (almost) absolute. Government is exempt, and there are certain other minor exemptions. But, outside of those, the patent holder can tell you to cease and desist.
Even if you have never sold a device.
Ratboy.
My apologies. The important sentence "got lost" for me, and I presumed you were still discussing the RIAA.
I should have caught it when extracting the quote, but didn't.
I am in the wrong.
Ratboy.
(Please use paragraphs)
You said that the RIAA:
"They pay talent scouts and agents to find artists they think you'll want to listen to. They buy/build/lease a building to use as a recording studio, build top-quality sets, buy high-end equipment, hire professionals to operate and maintain the equipment and buildings, often pay the artists up front, pay for the utilities used during production, pay other professionals to edit/remaster the tracks, pay artists to design the cover and disc art, and pay for the manufacture of the discs, cases, and covers. Then they pay salesmen to go out and find distributors for the albums."
The RIAA started by standardizing the equalization of records (too much bass, the needle jumps out of the groove... etc.). They now act as agents for labels and artists (copyright holders).
The RIAA doesn't engage in or pay for any of the activities you listed. Sorry to "burst your bubble".
The Artist pays for these activities. Either the Artist or the Label engages in the activities.
One point needs clarification: "often pay the artists up front". Yes, Labels do often front money to the Artist. However, that money is subtracted from the gross; as are all other production expenses.
Ratboy
Generally this (masquerading) is a problem with NFS. On a small LAN this isn't much of a big deal.
Several ways to solve the problem. First, UID and GID can be centrally controlled on a LAN by use of NIS. Still, if the machine is under the control of someone else, a forged UID/GID may be presented.
This can be controlled by the NFS server using "root squashing" or "all squash".
Both of these options "distrust" the UID/GID. In the case of root squash, root UID (0) is remapped to "nobody". This is a good thing on a LAN, because root file priviledge is contained. However, the attacker can obtain someone elses UID. Sensitive material should be encrypted. "All squash" option remaps all UIDs to "nobody" and is typically deployed for read-only shares, or "bulletin board" directories.
The security of your LAN is only as good as the security of the machines making up that LAN, anyway.
Ratboy