Huh? I don't know what you are trying to say here. If you aggregate an object, there is nothing that prevents you from making it accessible to classes that derive from you or even publicly accessible.
Yes, but the composite object is no longer the same type of object as the aggregated object.
If you never need to treat the composite object as the base type (dynamic runtime execution / polymorphism) then you are fine, and aggregation is indeed the better option.
If you need to preserve the type, then you are out of luck.
You only need multiple inheritance when your object must polymorphically substitute for more than one base object. In 99% of these cases, you are actually inheriting from multiple interfaces.
I would disagree here. If a base class inherits from some group of interfaces, and provides some basic functionality, i.e. implementation, for many of the interface operations, what happens when you need some further refinements on only a few operations?
You either create a new implemenation class derived from the interfaces, and duplicate code, aggregate the previous implemenation, or use multiple inheritance.
reimplementation is a waste of code.
aggregation re-uses code but breaks type compatibility with the base class. (aside from being a hack in my opinion. Forwarding the majority of operations to a member aggregate class would be annoying)
Thus, multiple inheritance can be a nice solution. Again, its not the only one, and its not right in all or even most cases, but there are some times where it saves a lot of grief and provides a better implementation and design.
Some C++ programmers even want to use private inheritance instead of aggregation!
Good point! If you find yourself with private inheritance, your doing something wrong. The only rational I can think of would be type preservation, but this would serve no purpose as you could not access the members of the preserved type.
At any rate, you brought up a major point. The majority of C++ coders misuse the langauge.
This is a major problem, and is related directly to the complexity of the C++ language itself.
However, this does not mean that all uses of multiple inheritance are misused or ill designed. In some cases, keyword SOME, it is very helpfull, and makes for a cleaner design and implementation.
pure virtual base classes, such as DynComponent and ReqCorba are equivalent (mostly) to Java interfaces.
True, you can have MyObject forward requests for BaseDynComponent and BaseReqCorba, but you can only have one interface of which it is an implementor of. (one pure virtual base class).
This works, and often time is a suitable solution, but sometimes it is not.
My sole point with the above is that once you remove multiple inheritance, you make some relationship hierarchies hard to implement, or cumbersome.
Many people would say that is an acceptable cost for a cleaner OO hierarchy, but my prefence is multiple inheritance.
I agree with most of your statement, like I said, not a good example, but I hoped it would show what I was trying to convey.
The point where I disagree is in multiple components aggregated into a larger component, instead of multiple inheritance.
Once you aggregate an object, it is now un accessible for future derivation. In most cases this is fine, in some it is not.
If you have a base class that does most of what you want, yet you want to customize a few operations, you have a few options:
- Derive from the base class and override the methods you want to customize further.
- Encapsulate the base class, and wrap the methods you want to customize (breaks type compatibility)
- Re-implement the base class and write the methods you want customized differently (waste of effort and duplicate code).
Granted, this is not your everyday scenario, but it does happen. My point is that when situation like this do occur, multiple inheritance is a good solution (not the only one, but a good one). The other possibilities may or may not be hard to implement, or all that difficult.
abstract class DynComponent abstract class ReqCorba
Two pure virtual base classes that define some interface requirements, one for a dynamic component interface, the other for some required CORBA interface operations.
Now we have two derived classes which implement some of the common functionality for these classes:
class BaseDynComponent : DynComponent
class BaseReqCorba : ReqCorba
Now we have an actual component that is a DynComponent object as well as a ReqCorba object.
We want to use the base functionality provided in BaseDynComponent and BaseReqCorba, so we make it derived from both:
class MyObject : BaseDynComponent, BaseReqCorba
Not a good example, but shows the gist of the problem.
There are a few reasons why I dislike Java on a purely technical basis:
- No multiple inheritance. None. Which means you either klidge your design, or use aggregation. Neither of which is pretty in a case where multiple inheritance would work best.
- Memory management. If you have a larger application, with complex processing, the memory manager can stall your application for hundreds of milliseconds during the full sweep garbage collection. They still have not solved this satisfactorilly. If your application has tight time contraints, this can be a severe problem.
- The finalize method of dervied classes must explicitly call the finalize method of the base class. Why in the hell did they do this?
There are some good points though, which, once the above are solved would make Java superior to most other languages:
- Incremental garbage collection. True incremental collection, with no more sweep checks.
- Threads. Java threads kick ass. Period.
- Libraries. Java has a library for everything under the sun.
- Portability. I love the fact that you can take a jar file and run it opn any VM (almost). This is a real time saver.
It's interesting to note in the article that only 50% of the royalties will go to the artists.
There is no packaging costs, no distribution costs, and the sites offering the music will be the ones doing all the work supplying and maintaining the digital databases, yet the RIAA stll wants its 50% cut of the revenue.
I suppose this is better than the estimated 15% artists currently get from CD sales, but still seems quite rediculous.
If the 'hackers' are SDMI employees or such, and this is simply an attempt to give credibility to a completely flawed process.
Perhaps they beleive that posing the contest as a legitimate, well executed test of the cryptographic properties of their watermarking systems will make the remaining UNBREAKABLE! cyphers seem bomb proof.
If they were to publish the attacks, complete with cryptanalysis and how the crack was discovered, I would have a bit more faith in the result.
P.S. I wonder how much they are going to charge to license these forced watermark encryption schemes...
Any protocol that uses UDP almost always uses sequences or packet identifiers. While you still may get a packet through the NAT, the application processing the UDP packets will recognize the invalid packet and ignore it.
Also, most NAT implementations do not keep track of TCP sequence numbers, this would be handled by the destined host to dump in the TCP stack.
Sequence numbers and identifiers are part of the overhead of UDP, but provided inherently in TCP.
See TFTP, BOOTP, etc, for example.
It is trivial to make UDP as spoof resistant as TCP. While it may not stop at the NAT, it still will not affect the application.
Once the connection is opened, the IP information in the internal table will be modified on both clients to the IP address/port of the NAT machine of the other client
This would be fine, except that it would require write access to kernel data structures which map the TCP connection information (local IP/Port and remote IP/Port).
Anyone else notice the part about the central Object Id database?
Just think how much grief ICANN has caused with the DNS root.
I love to think what the Object Id Root owner will be like.
This is a lame duck. Companies will probably love it (in theory), however, it cant function in the real world unless almost everyone adopts it.
And god knows that wont happen.
I love DSL. It is the greatest net connection one can have for 60 bucks a month.
But it is also the biggest headache you will ever encounter when obtaining net access (unless your trying to get an OC48 to your apartment)
I first called in for access in February. I was told it would be about 4 weeks before an install. My ADSL modem, network card, and low pass filters arrived within two weeks. No problems there.
About the 4 week mark, the tech arrived, as planned, and everything was setup and working properly. Only minor hitch was getting DHCP to work with my linux installation.
Well, everything was awesome. I was consistently able to get 1.2Mbps download, yes, 1.2Mbps. Upload was about 200Kbps.
It was pure heaven for a whole week. Then SWbell decides that they need to use PPPOE to authenticate DSL customers, and prevent users from getting 20+ DHCP leases, and tying up IP addresses.
Well, this fucked everything up. I could no longer get DHCP replies because the routes were fucked, and this left me dead in the water. They would not convert me to PPPOE, and even this wouldnt have solved the problem apparently.
After two and half months of getting nowhere, I gave in and bought the static IP package.
I now have 5 static IP addresses for my DSL line, and no worries with DHCP and all that crap.
And its back to 1.2Mbps.
Sweetness... as long as it works.
So, buyer beware, and expect problems, and lots of frustration. It will not be smooth. And if it is, its an anomoly, so be happy.
1) Every bit of information is NOT sent to every other client. Many requests are dropped, ignored, or simply do not reach their destination when the TTL expires.
2) The nature of the clients ensures that slow connections have fewer peers, propogate fewer requests, and receive fewer requests than faster ones.
These two attributes greatly reduce the theoretical maximums encountered when doing math.
The real world implementation does not even remotely follow the absolute mathematical predictions.
There is also a server oriented gnutella application which aims to start resolving some of these issues in the near term. Features such as:
1) Provide a server for broadband / dedicated network users to provide content with a true server oriented gnutella node. This will be similar to a modified apache for singular installations, or a federated distributed server architecture for routing and caching fun.
2) Remove broadcast push requests (in all future clients)
3) Proxy and cache support for slow users. This will allow beafy servers to take over some of the load which dialup / slower clients experience. This will be somewhat ala freenet, as popular data will propagate through caches in various nodes. Also, this can provide a level of anonymity which is not present.
4) Adaptive servers which configure their network connections for optimal efficiency. Not too busy, not too slow, and with the widest distance topologically from their peers (if linked) and fuzzy / reactive propogation algorithms so that TTL's and routes can be dynamically modified as load increases or other factors require.
There is nothing fundamentally flawed with the gnutella architecture, and it is far from a 'dead' horse'. However, there are significant innefficiencies and complications which are causing problems right now. Rest assured these will be fixed.
In Linux, all unused memory is used for filesystem caching. In general, linux does this caching mcuh better than you could by mounting specific disks and files in a RAMDISK. Linux chooses things which are accessed frequently, or very recently, among other things, into this FS chache.
By creating a RAM disk to do this, you would force a much smaller subset into memory, which would be great for what you are using there, but would hinder performance on other things which linux does not have the room to cache now.
So, unless there is something very specific that needs to be cached, there is no rationale for this, and the chances are that linux will cache it for you anyway if its that much of a performance hit.
Last but not least, the biggest reason RAM disks are slightly faster than average (when linux does cache) is because they never have to synch to a physical medium. If you dont care that all the data you have written there is gone *poof* once a crash occurs, or if the system is shutdown, then thats ok. If you have a file there, and 'oops' forgot to write it to disk, its gone.
We sense time. We just cannot universally sense specific quantities of time.
The mind is its own proof of concept. The fact that we perceive, is fact that 'it' perceives. You *are* your mind, your body is simply an input device.
Consciousness is sensed. Every thought you think, of which you are aware, is 'sensed; by your consciousness. You can't touch a thought, if that's what your getting at, but human senses are not truly limited to the 5 common ones.
The documents were verbatim copies of supposedly 'secret, very sensitive documents' that they were charging upwards of $50k for copies of. See the whole fish man story.
At any rate, there was no *abuse*, unless you call depriving them of the ability to charge clueless cult followers fifty grand for some fiction a crime or abuse.
What is this GPL your talking about? Don't fuck with us or we sue you out of existence?
They even sued a fucking cult awareness site, non profit, non biased, because of some sensitive information regarding member of the fucking scientologist crap.
They got sued out of existence, after all, non profit organisations dont stand against cults with $50k+ paperback fiction fanatics.
http://www.xmission.com/~count ry/reason/mormhist.htm - Mormon history by a mormon historian who had unprecedented access to church historical documents before they were again sealed (pretty much) back up in the archives.
/*
* css_descramble.c
*
* Released under the version 2 of the GPL.
*
* Copyright 1999 Derek Fawcus
*
* This file contains functions to descramble CSS encrypted DVD content
*
*/
/*
* Still in progress: Remove the use of the bit_reverse[] table by recoding
* the generation of LFSR1. Finish combining this with
* the css authentication code.
*
*/
#include
#include
#include "css-descramble.h"
typedef unsigned char byte;
/*
*
* some tables used for descrambling sectors and/or decrypting title keys
*
*/
/* Reverse the order of the bits within a byte.
*/
static byte bit_reverse[256]=
{
0x00,0x80,0x40,0xc0,0x20,0xa0,0x60,0xe0,0x10,0x90, 0x50,0xd0,0x30,0xb0,0x70,0xf0,
0x08,0x88,0x48,0xc8,0x28,0xa8,0x68,0xe8,0x18,0x98, 0x58,0xd8,0x38,0xb8,0x78,0xf8,
0x04,0x84,0x44,0xc4,0x24,0xa4,0x64,0xe4,0x14,0x94, 0x54,0xd4,0x34,0xb4,0x74,0xf4,
0x0c,0x8c,0x4c,0xcc,0x2c,0xac,0x6c,0xec,0x1c,0x9c, 0x5c,0xdc,0x3c,0xbc,0x7c,0xfc,
0x02,0x82,0x42,0xc2,0x22,0xa2,0x62,0xe2,0x12,0x92, 0x52,0xd2,0x32,0xb2,0x72,0xf2,
0x0a,0x8a,0x4a,0xca,0x2a,0xaa,0x6a,0xea,0x1a,0x9a, 0x5a,0xda,0x3a,0xba,0x7a,0xfa,
0x06,0x86,0x46,0xc6,0x26,0xa6,0x66,0xe6,0x16,0x96, 0x56,0xd6,0x36,0xb6,0x76,0xf6,
0x0e,0x8e,0x4e,0xce,0x2e,0xae,0x6e,0xee,0x1e,0x9e, 0x5e,0xde,0x3e,0xbe,0x7e,0xfe,
0x01,0x81,0x41,0xc1,0x21,0xa1,0x61,0xe1,0x11,0x91, 0x51,0xd1,0x31,0xb1,0x71,0xf1,
0x09,0x89,0x49,0xc9,0x29,0xa9,0x69,0xe9,0x19,0x99, 0x59,0xd9,0x39,0xb9,0x79,0xf9,
0x05,0x85,0x45,0xc5,0x25,0xa5,0x65,0xe5,0x15,0x95, 0x55,0xd5,0x35,0xb5,0x75,0xf5,
0x0d,0x8d,0x4d,0xcd,0x2d,0xad,0x6d,0xed,0x1d,0x9d, 0x5d,0xdd,0x3d,0xbd,0x7d,0xfd,
0x03,0x83,0x43,0xc3,0x23,0xa3,0x63,0xe3,0x13,0x93, 0x53,0xd3,0x33,0xb3,0x73,0xf3,
0x0b,0x8b,0x4b,0xcb,0x2b,0xab,0x6b,0xeb,0x1b,0x9b, 0x5b,0xdb,0x3b,0xbb,0x7b,0xfb,
0x07,0x87,0x47,0xc7,0x27,0xa7,0x67,0xe7,0x17,0x97, 0x57,0xd7,0x37,0xb7,0x77,0xf7,
0x0f,0x8f,0x4f,0xcf,0x2f,0xaf,0x6f,0xef,0x1f,0x9f, 0x5f,0xdf,0x3f,0xbf,0x7f,0xff
};
/*
*
* this function is only used internally when decrypting title key
*
*/
static void css_titlekey(byte *key, byte *im, byte invert)
{
unsigned int lfsr1_lo,lfsr1_hi,lfsr0,combined;
byte o_lfsr0, o_lfsr1;
byte k[5];
int i;
lfsr1_lo = im[0] | 0x100;
lfsr1_hi = im[1];
lfsr0 = ((im[4] >8)&0xff] >16)&0xff]>24)&0xff];
combined = 0;
for (i = 0; i >1;
lfsr1_lo = ((lfsr1_lo&1)>7)^(lfsr0>>10)^(lfsr0>>11)^(lfsr0>>1 9);*/
o_lfsr0 = (((((((lfsr0>>8)^lfsr0)>>1)^lfsr0)>>3)^lfsr0)>>7); lfsr0 = (lfsr0>>8)|(o_lfsr0>= 8;
}
/*
*
* this function decrypts a title key with the specified disk key
*
* tkey: the unobfuscated title key (XORed with BusKey)
* dkey: the unobfuscated disk key (XORed with BusKey)
* 2048 bytes in length (though only 5 bytes are needed, see below)
* pkey: array of pointers to player keys and disk key offsets
*
*
* use the result returned in tkey with css_descramble
*
*/
int css_decrypttitlekey(byte *tkey, byte *dkey, struct playkey **pkey)
{
byte test[5], pretkey[5];
int i = 0;
You need to qualify your UNIX apps not using components with the word 'Open Source'
I can tell you that in industry, where companies hoard their wares under non discolsure and copyright, Unix and CORBA and various other component technologies are all over the place.
We just need more in open source. Unfortunately, a lot fo the people doing kick ass shit in industry dont give a fuck about writing cool shit for open source. They have enough to deal with for contracts, long hours, families, deadlines, blah blah...
Not like your college freshman blowing time for summer break can hack the kinda of well architectured reusable, extensible frameworks and components that would really kick ass.
No, learning to code is not copying people's work. If you want to learn to code, then use parts. peices. Toy with it. But dont make an entire copy of some fucking way overdone app and post it on freshmeat and consider yourself a baddass open source hacker.
Too bad most open source coders cant write their own new code. They simply recycle shit thats already written.
The number of innovative open source coders is much smaller than the imitating code monkeys cranking out the same shit thats been done before in a million different flavors.
Slashdot Mirror
Huh? I don't know what you are trying to say here. If you aggregate an object, there is nothing that prevents you from making it accessible to classes that derive from you or even publicly accessible.
Yes, but the composite object is no longer the same type of object as the aggregated object.
If you never need to treat the composite object as the base type (dynamic runtime execution / polymorphism) then you are fine, and aggregation is indeed the better option.
If you need to preserve the type, then you are out of luck.
You only need multiple inheritance when your object must polymorphically substitute for more than one base object. In 99% of these cases, you are actually inheriting from multiple interfaces.
I would disagree here. If a base class inherits from some group of interfaces, and provides some basic functionality, i.e. implementation, for many of the interface operations, what happens when you need some further refinements on only a few operations?
You either create a new implemenation class derived from the interfaces, and duplicate code, aggregate the previous implemenation, or use multiple inheritance.
reimplementation is a waste of code.
aggregation re-uses code but breaks type compatibility with the base class. (aside from being a hack in my opinion. Forwarding the majority of operations to a member aggregate class would be annoying)
Thus, multiple inheritance can be a nice solution. Again, its not the only one, and its not right in all or even most cases, but there are some times where it saves a lot of grief and provides a better implementation and design.
Some C++ programmers even want to use private inheritance instead of aggregation!
Good point! If you find yourself with private inheritance, your doing something wrong. The only rational I can think of would be type preservation, but this would serve no purpose as you could not access the members of the preserved type.
At any rate, you brought up a major point. The majority of C++ coders misuse the langauge.
This is a major problem, and is related directly to the complexity of the C++ language itself.
However, this does not mean that all uses of multiple inheritance are misused or ill designed. In some cases, keyword SOME, it is very helpfull, and makes for a cleaner design and implementation.
pure virtual base classes, such as DynComponent and ReqCorba are equivalent (mostly) to Java interfaces.
True, you can have MyObject forward requests for BaseDynComponent and BaseReqCorba, but you can only have one interface of which it is an implementor of. (one pure virtual base class).
This works, and often time is a suitable solution, but sometimes it is not.
My sole point with the above is that once you remove multiple inheritance, you make some relationship hierarchies hard to implement, or cumbersome.
Many people would say that is an acceptable cost for a cleaner OO hierarchy, but my prefence is multiple inheritance.
I agree with most of your statement, like I said, not a good example, but I hoped it would show what I was trying to convey.
The point where I disagree is in multiple components aggregated into a larger component, instead of multiple inheritance.
Once you aggregate an object, it is now un accessible for future derivation. In most cases this is fine, in some it is not.
If you have a base class that does most of what you want, yet you want to customize a few operations, you have a few options:
- Derive from the base class and override the methods you want to customize further.
- Encapsulate the base class, and wrap the methods you want to customize (breaks type compatibility)
- Re-implement the base class and write the methods you want customized differently (waste of effort and duplicate code).
Granted, this is not your everyday scenario, but it does happen. My point is that when situation like this do occur, multiple inheritance is a good solution (not the only one, but a good one). The other possibilities may or may not be hard to implement, or all that difficult.
abstract class DynComponent
abstract class ReqCorba
Two pure virtual base classes that define some interface requirements, one for a dynamic component interface, the other for some required CORBA interface operations.
Now we have two derived classes which implement some of the common functionality for these classes:
class BaseDynComponent : DynComponent
class BaseReqCorba : ReqCorba
Now we have an actual component that is a DynComponent object as well as a ReqCorba object.
We want to use the base functionality provided in BaseDynComponent and BaseReqCorba, so we make it derived from both:
class MyObject : BaseDynComponent, BaseReqCorba
Not a good example, but shows the gist of the problem.
There are a few reasons why I dislike Java on a purely technical basis:
;)
- No multiple inheritance. None. Which means you either klidge your design, or use aggregation. Neither of which is pretty in a case where multiple inheritance would work best.
- Memory management. If you have a larger application, with complex processing, the memory manager can stall your application for hundreds of milliseconds during the full sweep garbage collection. They still have not solved this satisfactorilly. If your application has tight time contraints, this can be a severe problem.
- The finalize method of dervied classes must explicitly call the finalize method of the base class. Why in the hell did they do this?
There are some good points though, which, once the above are solved would make Java superior to most other languages:
- Incremental garbage collection. True incremental collection, with no more sweep checks.
- Threads. Java threads kick ass. Period.
- Libraries. Java has a library for everything under the sun.
- Portability. I love the fact that you can take a jar file and run it opn any VM (almost). This is a real time saver.
Your mileage may vary...
It's interesting to note in the article that only 50% of the royalties will go to the artists.
There is no packaging costs, no distribution costs, and the sites offering the music will be the ones doing all the work supplying and maintaining the digital databases, yet the RIAA stll wants its 50% cut of the revenue.
I suppose this is better than the estimated 15% artists currently get from CD sales, but still seems quite rediculous.
If the 'hackers' are SDMI employees or such, and this is simply an attempt to give credibility to a completely flawed process.
Perhaps they beleive that posing the contest as a legitimate, well executed test of the cryptographic properties of their watermarking systems will make the remaining UNBREAKABLE! cyphers seem bomb proof.
If they were to publish the attacks, complete with cryptanalysis and how the crack was discovered, I would have a bit more faith in the result.
P.S. I wonder how much they are going to charge to license these forced watermark encryption schemes...
Any protocol that uses UDP almost always uses sequences or packet identifiers. While you still may get a packet through the NAT, the application processing the UDP packets will recognize the invalid packet and ignore it.
Also, most NAT implementations do not keep track of TCP sequence numbers, this would be handled by the destined host to dump in the TCP stack.
Sequence numbers and identifiers are part of the overhead of UDP, but provided inherently in TCP.
See TFTP, BOOTP, etc, for example.
It is trivial to make UDP as spoof resistant as TCP. While it may not stop at the NAT, it still will not affect the application.
Once the connection is opened, the IP information in the internal table will be modified on both clients to the IP address/port of the NAT machine of the other client
:(
This would be fine, except that it would require write access to kernel data structures which map the TCP connection information (local IP/Port and remote IP/Port).
Needless to say, this is not an option.
Anyone else notice the part about the central Object Id database? Just think how much grief ICANN has caused with the DNS root. I love to think what the Object Id Root owner will be like. This is a lame duck. Companies will probably love it (in theory), however, it cant function in the real world unless almost everyone adopts it. And god knows that wont happen.
I love DSL. It is the greatest net connection one can have for 60 bucks a month.
But it is also the biggest headache you will ever encounter when obtaining net access (unless your trying to get an OC48 to your apartment)
I first called in for access in February. I was told it would be about 4 weeks before an install. My ADSL modem, network card, and low pass filters arrived within two weeks. No problems there.
About the 4 week mark, the tech arrived, as planned, and everything was setup and working properly. Only minor hitch was getting DHCP to work with my linux installation.
Well, everything was awesome. I was consistently able to get 1.2Mbps download, yes, 1.2Mbps. Upload was about 200Kbps.
It was pure heaven for a whole week. Then SWbell decides that they need to use PPPOE to authenticate DSL customers, and prevent users from getting 20+ DHCP leases, and tying up IP addresses.
Well, this fucked everything up. I could no longer get DHCP replies because the routes were fucked, and this left me dead in the water. They would not convert me to PPPOE, and even this wouldnt have solved the problem apparently.
After two and half months of getting nowhere, I gave in and bought the static IP package.
I now have 5 static IP addresses for my DSL line, and no worries with DHCP and all that crap.
And its back to 1.2Mbps.
Sweetness... as long as it works.
So, buyer beware, and expect problems, and lots of frustration. It will not be smooth. And if it is, its an anomoly, so be happy.
You forget a few vital points.
1) Every bit of information is NOT sent to every other client. Many requests are dropped, ignored, or simply do not reach their destination when the TTL expires.
2) The nature of the clients ensures that slow connections have fewer peers, propogate fewer requests, and receive fewer requests than faster ones.
These two attributes greatly reduce the theoretical maximums encountered when doing math.
The real world implementation does not even remotely follow the absolute mathematical predictions.
There is a way to start resolving this problem, and it is currently in development.
e &folderId=136401&pageId=177268&JServSess ionId=3fe61b505308701b.415222.969643886549
The gPulp project is currently working on all of these issues. Check proposals and ideas at: http://gnutellang.we go.com/go/wego.pages.page?groupId=133015&view=pag
There is also a server oriented gnutella application which aims to start resolving some of these issues in the near term. Features such as:
1) Provide a server for broadband / dedicated network users to provide content with a true server oriented gnutella node. This will be similar to a modified apache for singular installations, or a federated distributed server architecture for routing and caching fun.
2) Remove broadcast push requests (in all future clients)
3) Proxy and cache support for slow users. This will allow beafy servers to take over some of the load which dialup / slower clients experience. This will be somewhat ala freenet, as popular data will propagate through caches in various nodes. Also, this can provide a level of anonymity which is not present.
4) Adaptive servers which configure their network connections for optimal efficiency. Not too busy, not too slow, and with the widest distance topologically from their peers (if linked) and fuzzy / reactive propogation algorithms so that TTL's and routes can be dynamically modified as load increases or other factors require.
There is nothing fundamentally flawed with the gnutella architecture, and it is far from a 'dead' horse'. However, there are significant innefficiencies and complications which are causing problems right now. Rest assured these will be fixed.
In Linux, all unused memory is used for filesystem caching. In general, linux does this caching mcuh better than you could by mounting specific disks and files in a RAMDISK. Linux chooses things which are accessed frequently, or very recently, among other things, into this FS chache.
By creating a RAM disk to do this, you would force a much smaller subset into memory, which would be great for what you are using there, but would hinder performance on other things which linux does not have the room to cache now.
So, unless there is something very specific that needs to be cached, there is no rationale for this, and the chances are that linux will cache it for you anyway if its that much of a performance hit.
Last but not least, the biggest reason RAM disks are slightly faster than average (when linux does cache) is because they never have to synch to a physical medium. If you dont care that all the data you have written there is gone *poof* once a crash occurs, or if the system is shutdown, then thats ok. If you have a file there, and 'oops' forgot to write it to disk, its gone.
Sorry, your wrong.
We sense time. We just cannot universally sense specific quantities of time.
The mind is its own proof of concept. The fact that we perceive, is fact that 'it' perceives. You *are* your mind, your body is simply an input device.
Consciousness is sensed. Every thought you think, of which you are aware, is 'sensed; by your consciousness. You can't touch a thought, if that's what your getting at, but human senses are not truly limited to the 5 common ones.
Dude, you have no fucking clue.
The documents were verbatim copies of supposedly 'secret, very sensitive documents' that they were charging upwards of $50k for copies of. See the whole fish man story.
At any rate, there was no *abuse*, unless you call depriving them of the ability to charge clueless cult followers fifty grand for some fiction a crime or abuse.
What is this GPL your talking about? Don't fuck with us or we sue you out of existence?
They even sued a fucking cult awareness site, non profit, non biased, because of some sensitive information regarding member of the fucking scientologist crap.
They got sued out of existence, after all, non profit organisations dont stand against cults with $50k+ paperback fiction fanatics.
Get a grip man.
Have you ever used the internet to learn about your religion?
Other members experiences?
History and events?
Quite interesting.
"The truth shall set ye free"
"The gift of the Holy Ghost to discern truth from deception"
http://www.adherents.com/largecom/co m_lds.html - demographic stats, pretty detailed, but old (1990)
http://www.xmission.com/~count ry/reason/mormhist.htm - Mormon history by a mormon historian who had unprecedented access to church historical documents before they were again sealed (pretty much) back up in the archives.
http://www.teleport.com/~packham/templ es.htm - Temple info
Etc.
Hmm.. i bet AOL is working on a "Sunday Services" program. LOL
Apparently you completely overlook the abuse, censor tatics used by Scientology to shut up detractors or people leaking 'sensitive' information.
The Scientologists were the first to assualt web freedoms with legal bullying.
Wonderful daily contributions they make.
http://www.cubicmetercrystal.com/decss/
/*
, 0x36,0x2b,0x6e,0x2e,0x66,0x7b,
, 0xd6,0x0b,0x4e,0x0e,0x46,0x9b,
, 0x52,0x8f,0xca,0x8a,0xc2,0x1f,
, 0xd0,0x01,0x48,0x08,0x40,0x91,
, 0x34,0x25,0x6c,0x2c,0x64,0x75,
, 0xd4,0x05,0x4c,0x0c,0x44,0x95,
, 0x50,0x81,0xc8,0x88,0xc0,0x11,
, 0xd2,0x0f,0x4a,0x0a,0x42,0x9f,
, 0x56,0x8b,0xce,0x8e,0xc6,0x1b,
, 0xb6,0xab,0xee,0xae,0xe6,0xfb,
, 0x32,0x2f,0x6a,0x2a,0x62,0x7f,
, 0xb0,0xa1,0xe8,0xa8,0xe0,0xf1,
, 0x54,0x85,0xcc,0x8c,0xc4,0x15,
, 0xb4,0xa5,0xec,0xac,0xe4,0xf5,
, 0x30,0x21,0x68,0x28,0x60,0x71,
, 0xb2,0xaf,0xea,0xaa,0xe2,0xff
, 0x0b,0x0a,0x0d,0x0c,0x0f,0x0e,
, 0x19,0x18,0x1f,0x1e,0x1d,0x1c,
, 0x2f,0x2e,0x29,0x28,0x2b,0x2a,
, 0x3d,0x3c,0x3b,0x3a,0x39,0x38,
, 0x42,0x43,0x44,0x45,0x46,0x47,
, 0x50,0x51,0x56,0x57,0x54,0x55,
, 0x66,0x67,0x60,0x61,0x62,0x63,
, 0x74,0x75,0x72,0x73,0x70,0x71,
, 0x99,0x98,0x9f,0x9e,0x9d,0x9c,
, 0x8b,0x8a,0x8d,0x8c,0x8f,0x8e,
, 0xbd,0xbc,0xbb,0xba,0xb9,0xb8,
, 0xaf,0xae,0xa9,0xa8,0xab,0xaa,
, 0xd0,0xd1,0xd6,0xd7,0xd4,0xd5,
, 0xc2,0xc3,0xc4,0xc5,0xc6,0xc7,
, 0xf4,0xf5,0xf2,0xf3,0xf0,0xf1,
, 0xe6,0xe7,0xe0,0xe1,0xe2,0xe3
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff,
, 0x49,0x6d,0x92,0xb6,0xdb,0xff
, 0x50,0xd0,0x30,0xb0,0x70,0xf0,
, 0x58,0xd8,0x38,0xb8,0x78,0xf8,
, 0x54,0xd4,0x34,0xb4,0x74,0xf4,
, 0x5c,0xdc,0x3c,0xbc,0x7c,0xfc,
, 0x52,0xd2,0x32,0xb2,0x72,0xf2,
, 0x5a,0xda,0x3a,0xba,0x7a,0xfa,
, 0x56,0xd6,0x36,0xb6,0x76,0xf6,
, 0x5e,0xde,0x3e,0xbe,0x7e,0xfe,
, 0x51,0xd1,0x31,0xb1,0x71,0xf1,
, 0x59,0xd9,0x39,0xb9,0x79,0xf9,
, 0x55,0xd5,0x35,0xb5,0x75,0xf5,
, 0x5d,0xdd,0x3d,0xbd,0x7d,0xfd,
, 0x53,0xd3,0x33,0xb3,0x73,0xf3,
, 0x5b,0xdb,0x3b,0xbb,0x7b,0xfb,
, 0x57,0xd7,0x37,0xb7,0x77,0xf7,
, 0x5f,0xdf,0x3f,0xbf,0x7f,0xff
1 9);*/
;
1 9);*/
;
* css_descramble.c
*
* Released under the version 2 of the GPL.
*
* Copyright 1999 Derek Fawcus
*
* This file contains functions to descramble CSS encrypted DVD content
*
*/
/*
* Still in progress: Remove the use of the bit_reverse[] table by recoding
* the generation of LFSR1. Finish combining this with
* the css authentication code.
*
*/
#include
#include
#include "css-descramble.h"
typedef unsigned char byte;
/*
*
* some tables used for descrambling sectors and/or decrypting title keys
*
*/
static byte csstab1[256]=
{
0x33,0x73,0x3b,0x26,0x63,0x23,0x6b,0x76,0x3e,0x7e
0xd3,0x93,0xdb,0x06,0x43,0x03,0x4b,0x96,0xde,0x9e
0x57,0x17,0x5f,0x82,0xc7,0x87,0xcf,0x12,0x5a,0x1a
0xd9,0x99,0xd1,0x00,0x49,0x09,0x41,0x90,0xd8,0x98
0x3d,0x7d,0x35,0x24,0x6d,0x2d,0x65,0x74,0x3c,0x7c
0xdd,0x9d,0xd5,0x04,0x4d,0x0d,0x45,0x94,0xdc,0x9c
0x59,0x19,0x51,0x80,0xc9,0x89,0xc1,0x10,0x58,0x18
0xd7,0x97,0xdf,0x02,0x47,0x07,0x4f,0x92,0xda,0x9a
0x53,0x13,0x5b,0x86,0xc3,0x83,0xcb,0x16,0x5e,0x1e
0xb3,0xf3,0xbb,0xa6,0xe3,0xa3,0xeb,0xf6,0xbe,0xfe
0x37,0x77,0x3f,0x22,0x67,0x27,0x6f,0x72,0x3a,0x7a
0xb9,0xf9,0xb1,0xa0,0xe9,0xa9,0xe1,0xf0,0xb8,0xf8
0x5d,0x1d,0x55,0x84,0xcd,0x8d,0xc5,0x14,0x5c,0x1c
0xbd,0xfd,0xb5,0xa4,0xed,0xad,0xe5,0xf4,0xbc,0xfc
0x39,0x79,0x31,0x20,0x69,0x29,0x61,0x70,0x38,0x78
0xb7,0xf7,0xbf,0xa2,0xe7,0xa7,0xef,0xf2,0xba,0xfa
};
static byte lfsr1_bits0[256]=
{
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x09,0x08
0x12,0x13,0x10,0x11,0x16,0x17,0x14,0x15,0x1b,0x1a
0x24,0x25,0x26,0x27,0x20,0x21,0x22,0x23,0x2d,0x2c
0x36,0x37,0x34,0x35,0x32,0x33,0x30,0x31,0x3f,0x3e
0x49,0x48,0x4b,0x4a,0x4d,0x4c,0x4f,0x4e,0x40,0x41
0x5b,0x5a,0x59,0x58,0x5f,0x5e,0x5d,0x5c,0x52,0x53
0x6d,0x6c,0x6f,0x6e,0x69,0x68,0x6b,0x6a,0x64,0x65
0x7f,0x7e,0x7d,0x7c,0x7b,0x7a,0x79,0x78,0x76,0x77
0x92,0x93,0x90,0x91,0x96,0x97,0x94,0x95,0x9b,0x9a
0x80,0x81,0x82,0x83,0x84,0x85,0x86,0x87,0x89,0x88
0xb6,0xb7,0xb4,0xb5,0xb2,0xb3,0xb0,0xb1,0xbf,0xbe
0xa4,0xa5,0xa6,0xa7,0xa0,0xa1,0xa2,0xa3,0xad,0xac
0xdb,0xda,0xd9,0xd8,0xdf,0xde,0xdd,0xdc,0xd2,0xd3
0xc9,0xc8,0xcb,0xca,0xcd,0xcc,0xcf,0xce,0xc0,0xc1
0xff,0xfe,0xfd,0xfc,0xfb,0xfa,0xf9,0xf8,0xf6,0xf7
0xed,0xec,0xef,0xee,0xe9,0xe8,0xeb,0xea,0xe4,0xe5
};
static byte lfsr1_bits1[512]=
{
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
0x00,0x24,0x49,0x6d,0x92,0xb6,0xdb,0xff,0x00,0x24
};
/* Reverse the order of the bits within a byte.
*/
static byte bit_reverse[256]=
{
0x00,0x80,0x40,0xc0,0x20,0xa0,0x60,0xe0,0x10,0x90
0x08,0x88,0x48,0xc8,0x28,0xa8,0x68,0xe8,0x18,0x98
0x04,0x84,0x44,0xc4,0x24,0xa4,0x64,0xe4,0x14,0x94
0x0c,0x8c,0x4c,0xcc,0x2c,0xac,0x6c,0xec,0x1c,0x9c
0x02,0x82,0x42,0xc2,0x22,0xa2,0x62,0xe2,0x12,0x92
0x0a,0x8a,0x4a,0xca,0x2a,0xaa,0x6a,0xea,0x1a,0x9a
0x06,0x86,0x46,0xc6,0x26,0xa6,0x66,0xe6,0x16,0x96
0x0e,0x8e,0x4e,0xce,0x2e,0xae,0x6e,0xee,0x1e,0x9e
0x01,0x81,0x41,0xc1,0x21,0xa1,0x61,0xe1,0x11,0x91
0x09,0x89,0x49,0xc9,0x29,0xa9,0x69,0xe9,0x19,0x99
0x05,0x85,0x45,0xc5,0x25,0xa5,0x65,0xe5,0x15,0x95
0x0d,0x8d,0x4d,0xcd,0x2d,0xad,0x6d,0xed,0x1d,0x9d
0x03,0x83,0x43,0xc3,0x23,0xa3,0x63,0xe3,0x13,0x93
0x0b,0x8b,0x4b,0xcb,0x2b,0xab,0x6b,0xeb,0x1b,0x9b
0x07,0x87,0x47,0xc7,0x27,0xa7,0x67,0xe7,0x17,0x97
0x0f,0x8f,0x4f,0xcf,0x2f,0xaf,0x6f,0xef,0x1f,0x9f
};
/*
*
* this function is only used internally when decrypting title key
*
*/
static void css_titlekey(byte *key, byte *im, byte invert)
{
unsigned int lfsr1_lo,lfsr1_hi,lfsr0,combined;
byte o_lfsr0, o_lfsr1;
byte k[5];
int i;
lfsr1_lo = im[0] | 0x100;
lfsr1_hi = im[1];
lfsr0 = ((im[4] >8)&0xff] >16)&0xff]>24)&0xff];
combined = 0;
for (i = 0; i >1;
lfsr1_lo = ((lfsr1_lo&1)>7)^(lfsr0>>10)^(lfsr0>>11)^(lfsr0>>
o_lfsr0 = (((((((lfsr0>>8)^lfsr0)>>1)^lfsr0)>>3)^lfsr0)>>7)
lfsr0 = (lfsr0>>8)|(o_lfsr0>= 8;
}
key[4]=k[4]^csstab1[key[4]]^key[3];
key[3]=k[3]^csstab1[key[3]]^key[2];
key[2]=k[2]^csstab1[key[2]]^key[1];
key[1]=k[1]^csstab1[key[1]]^key[0];
key[0]=k[0]^csstab1[key[0]]^key[4];
key[4]=k[4]^csstab1[key[4]]^key[3];
key[3]=k[3]^csstab1[key[3]]^key[2];
key[2]=k[2]^csstab1[key[2]]^key[1];
key[1]=k[1]^csstab1[key[1]]^key[0];
key[0]=k[0]^csstab1[key[0]];
}
/*
*
* this function decrypts a title key with the specified disk key
*
* tkey: the unobfuscated title key (XORed with BusKey)
* dkey: the unobfuscated disk key (XORed with BusKey)
* 2048 bytes in length (though only 5 bytes are needed, see below)
* pkey: array of pointers to player keys and disk key offsets
*
*
* use the result returned in tkey with css_descramble
*
*/
int css_decrypttitlekey(byte *tkey, byte *dkey, struct playkey **pkey)
{
byte test[5], pretkey[5];
int i = 0;
for (; *pkey; ++pkey, ++i) {
memcpy(pretkey, dkey + (*pkey)->offset, 5);
css_titlekey(pretkey, (*pkey)->key, 0);
memcpy(test, dkey, 5);
css_titlekey(test, pretkey, 0);
if (memcmp(test, pretkey, 5) == 0) {
fprintf(stderr, "Using Key %d\n", i+1);
break;
}
}
if (!*pkey) {
fprintf(stderr, "Shit - Need Key %d\n", i+1);
return 0;
}
css_titlekey(tkey, pretkey, 0xff);
return 1;
}
/*
*
* this function does the actual descrambling
*
* sec: encrypted sector (2048 bytes)
* key: decrypted title key obtained from css_decrypttitlekey
*
*/
void css_descramble(byte *sec,byte *key)
{
unsigned int lfsr1_lo,lfsr1_hi,lfsr0,combined;
unsigned char o_lfsr0, o_lfsr1;
unsigned char *end = sec + 0x800;
#define SALTED(i) (key[i] ^ sec[0x54 + (i)])
lfsr1_lo = SALTED(0) | 0x100;
lfsr1_hi = SALTED(1);
lfsr0 = ((SALTED(4) >8)&0xff] >16)&0xff]>24)&0xff];
sec+=0x80;
combined = 0;
while (sec != end) {
o_lfsr1 = lfsr1_bits0[lfsr1_hi] ^ lfsr1_bits1[lfsr1_lo];
lfsr1_hi = lfsr1_lo>>1;
lfsr1_lo = ((lfsr1_lo&1)>7)^(lfsr0>>10)^(lfsr0>>11)^(lfsr0>>
o_lfsr0 = (((((((lfsr0>>8)^lfsr0)>>1)^lfsr0)>>3)^lfsr0)>>7)
lfsr0 = (lfsr0>>8)|(o_lfsr0>= 8;
}
}
True. It sno big harm. They just annoy me.
And my patience is thin. I need to get laid.
You need to qualify your UNIX apps not using components with the word 'Open Source'
I can tell you that in industry, where companies hoard their wares under non discolsure and copyright, Unix and CORBA and various other component technologies are all over the place.
We just need more in open source. Unfortunately, a lot fo the people doing kick ass shit in industry dont give a fuck about writing cool shit for open source. They have enough to deal with for contracts, long hours, families, deadlines, blah blah...
Not like your college freshman blowing time for summer break can hack the kinda of well architectured reusable, extensible frameworks and components that would really kick ass.
use CORBA.
(damnit Rob, i have the sentence "use CORBA" and that fucking lameness filter freaks.)
No, learning to code is not copying people's work. If you want to learn to code, then use parts. peices. Toy with it. But dont make an entire copy of some fucking way overdone app and post it on freshmeat and consider yourself a baddass open source hacker.
Too bad most open source coders cant write their own new code. They simply recycle shit thats already written.
The number of innovative open source coders is much smaller than the imitating code monkeys cranking out the same shit thats been done before in a million different flavors.