I have used Jalindi Igloo successfully, and its an excellent piece of work. It makes access to the repository transparent, as does VSS integration into VS.
While I like CVS, and attempted at one point to get my company to move to it, I have to admit that there are a lot of features in VSS that make it more powerful than CVS. This includes "little things" like versioning of directories (so when you check out a label you get exactly the right files (and file versions) and directories. File sharing is also incredibly useful (we have several projects that have to share header and/or source files, in a case where libraries aren't an option).
Before you rush to move off VSS, consider your situation carefully. If you have a large history of development in your repository (as we did), then you are going to lose all of that in moving to CVS!! There is no tool which can take all your revision history with you.
CVS has been network access (for non-local networks) than VSS, but poorer tools; and in the case of VC the integration is not as good. VSS is a more stable product than many people give it credit for; but yes, databases do become corrupt (I've seen this with CVS too, when the server went down unexpectedly). Backup is always your best line of defense against corruption.
This technology allows for authentication. Given a file and a registry of public keys, you can be certain that the file is an identical copy of the one reviewed by the notary represented by the public key.
In the case of music, you could be certain that you have a copy of the genuine original, not a track modified by someone else. Artists and/or record companies could sign digital music files so that you know you aren't getting a modified version.
But this technology doesn't extend to copy control / protection. It does not consider the viewer/user at all, only the originator.
I could be missing something here... but has anyone READ this treaty? I can find no reference to an onus on a signatory to enact law that will force the disclosure of passwords.
The treaty bans: illegal access and interception, data or system interference, and misuse of device (with Article 6(2) specifically putting in a way out for testing software). Forgery and fraud are also on the no-no list.
The child porno regulations are overly broad because they include "realistic images" are porno, and define a minor as under 18 (16 at a push). This screws nations where the age of consent is low (as low as 14) and banning images can restrict education about child abuse.
The Copyright provisions basically say that you must be a signatory to the Bern and Rome Conventions, and that you must enact legislation to outlaw wilful violations on a commercial scale.
The adoption of many of these provisions (or at least the nastiest parts of them) is optional.
Article 15 explicitly limits the application of the treaty to protect human rights and have the powers afforded under the treaty reasonably limited.
As for "phone tapping" - provision is made for data preservation 'on demand', not for disclosure. A service provider must preserve data on request for up to 90 days, to give authorities a chance to request (through a normal court process) disclosure.
I can find no reference to disclosure of passwords. If you are responsible for a computer system you may be required to submit data, which implies that you may be required to decode it if it is encoded. That could implicitly place an onus on any system administrator to have backdoor access to everything on the system.
More worrying though is that every subscriber will need to be able to supply information about users of their service, including identity and address. While this is limited to the "information available on the basis of the service agreement", SPs (including Internet Cafes and ASPs) may have to get proof of identity from you to cover themselves.
Article 19(4) is the bit that everything is shitting themselves about: 4. Each Party shall adopt such legislative and other measures as may be necessary to empower its competent authorities to order any person who has knowledge about the functioning of the computer system or measures applied to protect the computer data therein to provide, as is reasonable, the necessary information, to enable the undertaking of the measures referred to in paragraphs 1 and 2. I think this speak for itself; if you know how to access the data, they can order you to do it.
ISPs should worry about the provisions for collection and interception, but the Treaty states "within [their] existing technical capacity". The Treaty does not require ISPs to have the ability to do this!
The extradition provisions are a big grey and worrying, but only relate to offenses under the treaty. The mutual assistance clauses are similarly restricted to the monitoring and laws enacted under the treaty; i.e. if you don't have a problem with the laws YOUR country enacts to fulfil their obligation to this treaty, then you have no need to worry.
A lot of the FUD flying around on Slashdot related to the perception of what laws the US seems to want to enact in relation to this treaty. Most people seem oblivious to the provisions of the treaty itself, most of which are reasonably balanaced and aimed at identifying and preventing criminal activity, rather than screwing Joe Public.
If you're a cracker, a DDoSer or a script kiddie, then you have more of a problem. You get treated like a graffiti artist or basically anyone who defiles someone else's property.
If you're a hacker, by comparison, then you have permission to screw with your own system and find and report vulnerabilities.
There have been a couple of major points brough up in this debate:
The separation between/usr and/usr/local has existed for ages, and nearly separates base system and add-ons. It should be pointed out that / is also part of this "hierarchy", and contains a minimal boot-capable system.
Having a limited number of locations for binaries makes sense: there is no need for massive PATH variables, and recursive searching can cause security problems. Symlinks can effectively keep access to binaries in one place, while they actually live elsewhere.
Unix people are lax and following the sucky Windows model of putting everything into one directory.
Now (1) and (2) are good points to bear in mind... but please, those who support (3), get a life and use Windows sometime.
The unofficial standard on Windows is to install applications in Program Files\\; which is far better even than just , as it allows vendors to structure their common files. Basically, locality is everything.
The problem with Windows is its library search mechanism: it looks in the.exe's directory, and windows\system32 (or winnt, as the case may be). i.e. Windows itself places a limitation on hierarchical structure because you can't dynamically specify library paths.
Now extend this to *nix, without the limitation:/,/usr,/usr/opt,/usr/local and/opt become your base locations into which stuff can be installed.
/ stays the same - essential binaries necessary for booting and recovery./usr becomes all system utilities that are required and cannot be removed (unless you are seriously fiddling with the distribution). / and/usr keep the same structure as they currently have: none.
/usr/opt is the location for packages that come with the distribution, but are optional. Packages are grouped by "vendor", and then by "app" (read: group = directory). Binaries get symlinks into/usr/bin and libraries get sumlinks into/usr/lib.
/usr/local is for stuff you compile yourself./opt is for third party applications that you install. They use the same vendor and app catagorisation, and have symlinks to/usr/local/bin,/usr/local/lib,/opt/bin and/opt/lib, as appropriate.
Of course at this point we should probably add that we should employ/var,/usr/var,/usr/local/var and/opt/var directories; as well as/etc,/usr/etc,/usr/local/etc and/opt/etc, all with symlinks to the relevant files in their proper locations.
And there you have it: hierarchical segregation for them all and symlinks to bind them.
Aaah, but that's NOT true. For starters XML-RPC uses an EXTREMELY stripped down XML for encapsulation, using no attributes. SOAP requires an XML parser capable of understanding attributes and namespaces.
Furthermore XML-RPC is far easier to implement as a CGI-type application, because it requires no information from the HTTP headers. SOAP requires a SOAP-Action header to tell it what to do.
SOAP and XML-RPC are only trivial if your language happens to have a compliant (but not quiet, because these do not use valid XML documents) XML parser library too. And those aren't as common as some people think.
But I will agree that the XML-RPC spec is inconsistent!
The DoJ settlement is not ABOUT punishing MS. It is widely accepted that punishment will be useless. Ref. the other reply to my comment (the Sherman Act): MS can bat off a $10mil fine without feeling a thing. What then?
This settlement is about correcting the future, not making up for the past. As such we have to be proactive in ensuring that the situation of monopolistic abuse does not arise, but at the same time respect the rights of MS (which has rights as a juristic citizen) and its shareholders.
There are ways to balance that. Unfortunately most people who have the brains to see how much damage MS has done are too anti-MS to consider a route in which they aren't totally removed from the planet.
Bottom Line: if there were no shareholders, you wouldn't have a job in the first place.
I've been in this situation before. I worked February this year and didn't get paid because the company liquidated at the end of the month, and never bothered to inform the employees of its financial situation.
There is a concept called "fidiciary duty": A manager (CEO, whatever) has a duty to THE COMPANY to ensure that THE COMPANY survives; just as a person's survival instinct is a driving force. A manager who ignores making money to appease the employees is ignoring this duty, and endangering the longevity of the company. OTOH a manager who ignores employees by forcing the money issue even when it will hurt the company (either by being a bad business decision or losing employees which are valuable) is also ignoring this duty.
Its a fine line to walk, but ultimately you need money (from shareholders) to make money (from customers) to pay money (to employees).
You have to bear in mind that MS is a public company, with a responsibility to share holders: making money. The DoJ/MS deal is not about punishing MS for past offenses, but about bringing MS in line from this point onwards. But it still has to bear in mind that MS must be allowed to act as a business.
While I appreciate the sentiment in your comments, I feel some are an overreaction, verging on a penalty. Forcing MS to disclose its APIs, formats and protocols in advance of their publication is not going to happen; from a purely economic point of view it will be laughed at by the judge, let alone the implications on MS's rights to trade.
It would be reasonable to force MS to disclose this information AT THE TIME of publication. This does mean that MS will be ahead of the rest of the market, but that is NOT the problem! The problem is to disallow MS from preventing the market from "catching up".
If MS brings out a new product with new formats and protocols, it will attract some attention from the market. Within a few months competitors will have compatible products, so the bulk of adopters will not be forced down the MS path.
Regarding Office suites, there are several competitors on Windows, including Corel and Lotus.
As for prevention of using 3rd party components, this is a difficult one to justify. While there is no doubt that MS could circumvent requirements in this manner, such a limitation would force MS to use only open standards. Although I strongly support open standards and wish MS had to use them, it simply does not always make good business sense to avoid patent-encumbered technologies.
Please realise that any submission to the judge needs to have some level of balance. Recommending ridiculous or unworkable 'solutions' will not assist, and will likely get your comment into the ignore pile rather quickly.
IANA civil engineer, but I have spoken to several on this topic. And with no due respect, you're wrong:)
Every building is a new and unique challange, and the building environment changes far more than people may assume. An American engineer with 30+ years of experience in sky scrapers will be lost trying to build in London (where soil densities and high water table screw with foundations), Japan (where the buildings must resist regular earthquakes), South Africa (where steel-based structures corrode within a matter of years) or Paraguay (can you say "logistics").
Making a C compiler from the GCC source? make depend ; make. Or do you mean looking at the source and creating a whole new C compiler? That's not exactly a good parallel - that would be like looking at the WTC before Sept 11 and taking notes, and then rebuilding it. Not gonna happen.
The equivalent of rebuilding the WTC from blueprints would be to have the annotated design for a C compiler, including full object hierarchy, API and behavioural specification. Now give it to a programming team and tell them to implement.
Oh, one more thing. I want a more streamlines version of the WTC for thin clients. Please take out the central support columns because they are resource-intensive.
Very true. I was engineer/manager on a 9 month long project, and we hit our targets perfectly (except the last, because the company liquidated... ack!). My team and myself were familiar with the technologies involves, and understood the requirements, which is important.
Recently I calculated it would take two weeks to port some synchronization abstractions from Windows to Solaris. I was our by 50% because Solaris pthreads implementation is broken (wrt. recursive mutex locking) - a little-published fact that took several hours to prove (that it wasn't our implementation), and days to correct.
As a matter of habbit I build in 50% buffer time if I am mostly familiar with the concepts involved, 20% if I am absolutely certain, and 100% otherwise.
And the reason this doesn't happen with bridges? The engineering team starts with a meeting of the financial backers, planners, marketers and artists. The have a mockup (drawing and miniture model) of the bridge before they start the design work, so they know that the look is agreed upon, and the idea is technically feasable and likely to be within budget.
It is often that I read knowledgeless prattle on Slashdot... usually only from fellow commentors. This is not a troll, it is serious criticism of an article that is blatently wrong. Let's examine Mr. Oram's discussions of P2P...
Did Universities try to stop P2P? Napster, certainly. Probably many other file sharing systems too. Why on earth would they do that? Bandwidth, security, liability. I'll elaborate later.
Mr. Oram asserts that P2P is a great way to overcome limited resources. Then expounds on how Internet2 and IPv6 are going to remove the resource barriers to P2P.
Is P2P new? No. IRC's DCC extensions have been around for at least 8 years; ytalk is even older. The idea of dsitributing information on a whole lot of servers without central control is, surprise surprise, the basis for the Web. P2P simply involves direct communication between clients, at most using a server to mediate discovery.
I'm going to ignore the anti-DMCA dissertation, because its been heard before. It also has nothing to do with P2P; just a few specialised services that use P2P as a means to swap copyright information. If it wasn't for people like Mr Oram confusing P2P with specific P2P applications, then P2P as a whole wouldn't have a bad name.
A little later we hit the "IPv6 will help" argument, to which I can only say: security. Sure, you get rid of NAT. But at the risk of placing your device in the line of fire. Even if it is "secure by default" (so end users don't have to worry too much), it is still accessible from everywhere. That means DOS vulnerable, attack vulnerable when a security hole is found, and each and every individual is responsible for their own security. That doesn't work in corporate of group/organization networking. A central point needs primary control over security for the entire network. NAT, firewalls, and prevention of arbitary data coming IN to the network unsolicited are significant defenses against attack.
Which brings up the strongest point for universities to deny P2P: they would have to allow access to P2P services (yes, P2P is actually a client and a server on each machine) behind their firewalls, causing a security risk. Typically universities have a limited number of computers providing services behind firewalls, and take care to guard them against attack, and quarantine them in case of breach. With P2P, this approach goes out of the window.
For the same reason Mr Oram has ignored the security communities hatred of SOAP, a protocol explicitly designed to penetrate those nasty firewalls that administrators put up. Tell me, why don't we just set up a public inbound IP-over-TCPIP tunnel available on all firewalls so that we can get past them?
Now Mr Oram turns to debunking the security argument. Totally missing the point of course. You can encrypt and sign until your CPU is blue in the face, and still have zero security because your computer has been compromised. Unless you can adequately secure ALL services on your computer, you are insecure. One of the best ways to secure a service is to shut it down. The more services, the more ports of entry. Not surprisingly, P2P is a service.
Sendmail and apache serve massive amount of network traffic every day. They have taken years to mature to a point where they are mostly secure, yet new hacks are found for them every so often. How long until P2P implementations reach this level of maturity, and security?
The McAfee example is laughable, to say the least. Multitier client-server technology isn't P2P, not matter what this supposed expert wants to believe. Oh yes -- what was that announcement two weeks ago about an attack on the McAfee auto-upgrade feature?
While most of the assertions regarding bandwidth are true (shock!), Mr Oram is WAY OUT on the University issue. You see, students may be downloading the same amount irrespective of whether they use P2P or FTP... but there is the issue of UPLOADING. Having administered a network for just a small company at the time of Napsterism, I saw a massive increase in bandwidth use just from Napster fielding and responsing to queries, even before local users started downloading the music.
Finally we conclude by returning to nonsense: Seti@home is P2P?!? In what universe does distributed computing offloaded by a central server and in which none of the computing nodes communicate with each other get classified as P2P?
Please, Mr Oram. Understand at least the vaguest basics of a topic before spewing garbage about it.
[Start Flamebait] Please would the moderators have some knowledge of the topic BEFORE flagging things as "Interesting" or "Informative"[End flamebait]
XML solves the data format problem, and nothing more. It does not solve the interchange problem because apps still need to know where to locate relevant information in an XML doc, and how to interpret it. i.e. they have to have knowledge of the DTD and translate from the XML (structured according to the DTD) into their own internal format.
So instead of needing to create a reader for a binary EDI format, you plug in a bog standard parser and get named values. So it makes interchange EASIER for the programmer. Especially those with languages that don't do binary data very well.
God only knows what XSL has to do with "programming language design". XSL has two explicit goals: 1. (XSLT) a generic translation from one XML format to another. Why? Because everyone wants to use their OWN XML DTD, so to interact with umpteen other products you need to understand the DTDs of each... or you write an XSL for each to change it into your format. 2. (XSL:FO) display primitives to allow an XML document to be transformed into a display language, so we can see the damn thing.
This is not only about trust; it is about economics. Small development studios representing a single owner, or a partnership, produce a vast amount of software for the Internet. OpenSource development teams likewise have no corporate presence, and rely on the identities of individuals.
This may sound like an innocuous move now, but consider the general direction of the intellectual property movement. The only way to truely secure digital content is to tie it to an identified user. That means hardware capable of decrypting content on the fly using a user-specific key. It is unreasonably difficult to reencrypt each piece of content for different hardware, so a license certificate is used to associate the content key securely with the user's identity.
CPUs already exist to do this for secure computing applications, and its hardly improbably that Intel and/or MS have considered this as a route for development. Whether it is the hardware or the OS that enforces it doesn't matter awfully much: at some point a corporation is responsible for issuing a license certificate which will marshall the association between your software certificate and a user's identity certificate.
In other words, someone has the power to determine if your software is allowed to run on their hardware, or not. By denying you a developer certificate, they can prevent your software from running.
Right now that's not a reality. Unsigned code isn't prevented from running, it just causes a miriad of warning and threats which most users will back away from.
So the moral of the story is be a big corporate, pay lots of money, and your product will be used. Otherwise you're sleeping in the sewer, my friend.
Hmmm... I must be missing something. Thawte does not require developers to present their passport or drivers' license in person. They get the details and check with the records of the appropriate authority; there is no physical interview, no cross-check that you aren't quoting someone elses details. If you have their name and numbers, you can masquerade as them.
Companies? Pah. Give me R250 and I can buy a close corporation with a name, registration and CK number (this is in South Africa, btw). It doesn't take a genius to get a corp. certificate from there. If you have the $200 for the certificate, it shouldn't be stretching finances to find the additional $30 for the corp.
Oh... there's still no-one who is going to check that the company represents the people it claims to...
IANAE (engineer), but I have spoken to several in the wake of the attacks. Apparently the US is one of the few countries to use steel as a basis for the superstructure of skyscrapers. In many parts of the world it is simply not economically or physically viable to build in this manner.
For example in South Africa (in coastal regions) it is not unreasonable to expect the highest grade of stainless steel to corrode within 5 to 7 years. London I am told has similar problems given their summertime humidity, a problem shared with many Pacific Rim locations.
While buildings not built in this manner (steel superstructure) would be more resistant to fire, it is difficult to speculate on the outcome of such an attack. Most likely the building would not have collapsed, but would have been considered unstable beyond a certain floor (and the entire structure demolished and rebuilt).
The main thing that distinguishes Rebol is a tiny footprint, and ground-up design for interaction in a networked environment.
Technologically, you have no clue what.NET or Java are about. Java by virtue of syntax and documentation is probably the simplest of languages around, and both.NET and Java run as bytecode on interpretters.
But most important, Java (and to some extent.NET) is significant for real-world enterprise applications because it defines specifications for interoperability. J2EE is not about providing programming libraries; it is about providing standards.
Rebol falls flat on this count in the same way as every other programming language: you have to lock yourself into a vendor at API level, not at language level.
in the interest of world security? No. In the interests of Western security? Yes.
The US has refused to engage in disarmorment programs along with the rest of the world, and it will not allow UN weapons inspectors to view its stockpiles. Yet any other country with nasty toys must give them up and be at the mercy of the US.
3)... perhaps the US should have withdrawn its troops from Saudi Arabia in line with the requests from various Middle East countries, and Bin Laden's demands for the past 5 years. Especially since they have no business being there anyway.
Of course no-one can say for sure whether this would solve the problem, but a willingness to negotiate is essential in resolving conflict in a non-violent manner.
A concept which America has shown itself incapable of grasping.
The US is withholding Free Trade from Iraq. It has not allowed any other member of the world community to decide independantly how they wish to deal with Iraq: if a country does not ceed to the US imposed sanctions, it too faces sanctions from the US.
Terrorism involves the murder of innocents, terrorism is for cowards who have no respect for human life.
Innocence is subjective. As is terrorism.
America is bombing a nation that has supported terrorism against America. It does this after imposing sanctions against a country allied to that nation, sanctions that are causing slow death as millions starve. This act forms part of the motive for the terrorism against America. In bombing Afganistan, America is inflicting further civilian casualties.
Where is the respect for human life? America is as much to blame for murdering innocents as Bin Laden or the Taliban. Yet few people see it this way: economic sanctions, although often more crippling than all-out war, are socially acceptable. Bin Laden struck at the heart of America's economic power; an 'appropriate' response to abuse of that power.
The way I understand this, you have old clients, new clients, and a server that must handle both. And the server and new clients should support Unicode.
First, although this is probably obvious, I should note that if your data is primarily text, then you're looking at a 2Tb database when you start using Unicode (depending on the encoding).
My biggest issue is that if we start storing user data in unicode we will no longer be able to provide complete updates the legacy (pure ASCII) systems
This is sortof like supporting German language entry, and wanting to display it on English clients. Its not easy, but it can be done, to some extent. Most Unicode you encounter will have an equivalent ASCII representation; there are acceptable conversions for almost all non-Eastern character sets. You can serve up a converted representation to your ASCII clients.
DO NOT listen to the bullshit about serving up UTF-8 to ASCII clients. They can't understand it any more than I can understand German ; it will seem to work only for low-ASCII characters, but break for all others.
As for data validation, you are going to have to have two rulesets. One will be client-side ASCII; the other a unicode ruleset used by both the new client and the server. Incoming ASCII from the old client should be converted to equivalent Unicode (that's the easy part) before being validated.
Sorry, no realworld information here either ; certainly not on database that size.
What's with people assuming that UTF-8 is ASCII? Its not. UTF-8 is a multibyte representation, that just happens to coincide with ASCII for characters 0 through 127. After that it takes two bytes to encode a character, possibly more when you get to "big" characters.
A lot of civil liberties proponents lose the plot at some point, and viciously attack any attempts at monitoring or interception. While I'm all for screaming blue murder about wholesale invasion of data and privacy, there is a point at which the state investigatory power that be require legitimate access to communications.
No, this would not have stopped Bin Laden & co, who communicated in public. Nor will it stop many related activites. But it is extremely effective against fraud and crime syndicates. I come from a country where these crimes are rife, and most convictions follow some form of search warrant.
The dividing line between good and bad is the inclusion of the court system into the process. Courts can already give permission for physical searches and wiretaps, subject to the provision of prima facae evidence. This is good.
Enough evidence must exist to convince a court that there is likely to be a crime, and that a particular person/group is likely to be implicated, before such a warrant will be issued.
There should be no difference for digital communications. Wiretaps could be used along with equipment to translate the wire signal into packet data, but this is inefficient. Just a telecoms companies are obliged to cooperate with the police (FBI), so ISPs, arguably the carrier for TCP/IP based data, should be obliged to cooperate (although not necessarily at their own cost).
When it comes to encrypted communication, the lines blur a little more, but only a little. You can be prosecuted for refusing to acknowledge a search warrant, or for refusing to testing (except in cases involving the Fifth Ammendment; and many countries don't have an equivalent), or for withholding evidence; so you should be able to be prosecuted for not providing the cleartext to an encrypted communication and, if necessary, proving it is a decryption of the ciphertext.
Slashdot Mirror
I have used Jalindi Igloo successfully, and its an excellent piece of work. It makes access to the repository transparent, as does VSS integration into VS.
While I like CVS, and attempted at one point to get my company to move to it, I have to admit that there are a lot of features in VSS that make it more powerful than CVS. This includes "little things" like versioning of directories (so when you check out a label you get exactly the right files (and file versions) and directories. File sharing is also incredibly useful (we have several projects that have to share header and/or source files, in a case where libraries aren't an option).
Before you rush to move off VSS, consider your situation carefully. If you have a large history of development in your repository (as we did), then you are going to lose all of that in moving to CVS!! There is no tool which can take all your revision history with you.
CVS has been network access (for non-local networks) than VSS, but poorer tools; and in the case of VC the integration is not as good. VSS is a more stable product than many people give it credit for; but yes, databases do become corrupt (I've seen this with CVS too, when the server went down unexpectedly). Backup is always your best line of defense against corruption.
This technology allows for authentication. Given a file and a registry of public keys, you can be certain that the file is an identical copy of the one reviewed by the notary represented by the public key.
In the case of music, you could be certain that you have a copy of the genuine original, not a track modified by someone else. Artists and/or record companies could sign digital music files so that you know you aren't getting a modified version.
But this technology doesn't extend to copy control / protection. It does not consider the viewer/user at all, only the originator.
I could be missing something here ... but has anyone READ this treaty? I can find no reference to an onus on a signatory to enact law that will force the disclosure of passwords.
The treaty bans: illegal access and interception, data or system interference, and misuse of device (with Article 6(2) specifically putting in a way out for testing software). Forgery and fraud are also on the no-no list.
The child porno regulations are overly broad because they include "realistic images" are porno, and define a minor as under 18 (16 at a push). This screws nations where the age of consent is low (as low as 14) and banning images can restrict education about child abuse.
The Copyright provisions basically say that you must be a signatory to the Bern and Rome Conventions, and that you must enact legislation to outlaw wilful violations on a commercial scale.
The adoption of many of these provisions (or at least the nastiest parts of them) is optional.
Article 15 explicitly limits the application of the treaty to protect human rights and have the powers afforded under the treaty reasonably limited.
As for "phone tapping" - provision is made for data preservation 'on demand', not for disclosure. A service provider must preserve data on request for up to 90 days, to give authorities a chance to request (through a normal court process) disclosure.
I can find no reference to disclosure of passwords. If you are responsible for a computer system you may be required to submit data, which implies that you may be required to decode it if it is encoded. That could implicitly place an onus on any system administrator to have backdoor access to everything on the system.
More worrying though is that every subscriber will need to be able to supply information about users of their service, including identity and address. While this is limited to the "information available on the basis of the service agreement", SPs (including Internet Cafes and ASPs) may have to get proof of identity from you to cover themselves.
Article 19(4) is the bit that everything is shitting themselves about: 4. Each Party shall adopt such legislative and other measures as may be necessary to empower its competent authorities to order any person who has knowledge about the functioning of the computer system or measures applied to protect the computer data therein to provide, as is reasonable, the necessary information, to enable the undertaking of the measures referred to in paragraphs 1 and 2. I think this speak for itself; if you know how to access the data, they can order you to do it.
ISPs should worry about the provisions for collection and interception, but the Treaty states "within [their] existing technical capacity". The Treaty does not require ISPs to have the ability to do this!
The extradition provisions are a big grey and worrying, but only relate to offenses under the treaty. The mutual assistance clauses are similarly restricted to the monitoring and laws enacted under the treaty; i.e. if you don't have a problem with the laws YOUR country enacts to fulfil their obligation to this treaty, then you have no need to worry.
A lot of the FUD flying around on Slashdot related to the perception of what laws the US seems to want to enact in relation to this treaty. Most people seem oblivious to the provisions of the treaty itself, most of which are reasonably balanaced and aimed at identifying and preventing criminal activity, rather than screwing Joe Public.
If you're a cracker, a DDoSer or a script kiddie, then you have more of a problem. You get treated like a graffiti artist or basically anyone who defiles someone else's property.
If you're a hacker, by comparison, then you have permission to screw with your own system and find and report vulnerabilities.
There have been a couple of major points brough up in this debate:
Now (1) and (2) are good points to bear in mind ... but please, those who support (3), get a life and use Windows sometime.
The unofficial standard on Windows is to install applications in Program Files\\; which is far better even than just , as it allows vendors to structure their common files. Basically, locality is everything.
The problem with Windows is its library search mechanism: it looks in the .exe's directory, and windows\system32 (or winnt, as the case may be). i.e. Windows itself places a limitation on hierarchical structure because you can't dynamically specify library paths.
Now extend this to *nix, without the limitation: /, /usr, /usr/opt, /usr/local and /opt become your base locations into which stuff can be installed.
/ stays the same - essential binaries necessary for booting and recovery. /usr becomes all system utilities that are required and cannot be removed (unless you are seriously fiddling with the distribution). / and /usr keep the same structure as they currently have: none.
/usr/opt is the location for packages that come with the distribution, but are optional. Packages are grouped by "vendor", and then by "app" (read: group = directory). Binaries get symlinks into /usr/bin and libraries get sumlinks into /usr/lib.
/usr/local is for stuff you compile yourself. /opt is for third party applications that you install. They use the same vendor and app catagorisation, and have symlinks to /usr/local/bin, /usr/local/lib, /opt/bin and /opt/lib, as appropriate.
Of course at this point we should probably add that we should employ /var, /usr/var, /usr/local/var and /opt/var directories; as well as /etc, /usr/etc, /usr/local/etc and /opt/etc, all with symlinks to the relevant files in their proper locations.
And there you have it: hierarchical segregation for them all and symlinks to bind them.
Isn't this what symbolic links are for...?
Aaah, but that's NOT true. For starters XML-RPC uses an EXTREMELY stripped down XML for encapsulation, using no attributes. SOAP requires an XML parser capable of understanding attributes and namespaces.
Furthermore XML-RPC is far easier to implement as a CGI-type application, because it requires no information from the HTTP headers. SOAP requires a SOAP-Action header to tell it what to do.
SOAP and XML-RPC are only trivial if your language happens to have a compliant (but not quiet, because these do not use valid XML documents) XML parser library too. And those aren't as common as some people think.
But I will agree that the XML-RPC spec is inconsistent!
The DoJ settlement is not ABOUT punishing MS. It is widely accepted that punishment will be useless. Ref. the other reply to my comment (the Sherman Act): MS can bat off a $10mil fine without feeling a thing. What then?
This settlement is about correcting the future, not making up for the past. As such we have to be proactive in ensuring that the situation of monopolistic abuse does not arise, but at the same time respect the rights of MS (which has rights as a juristic citizen) and its shareholders.
There are ways to balance that. Unfortunately most people who have the brains to see how much damage MS has done are too anti-MS to consider a route in which they aren't totally removed from the planet.
Bottom Line: if there were no shareholders, you wouldn't have a job in the first place.
I've been in this situation before. I worked February this year and didn't get paid because the company liquidated at the end of the month, and never bothered to inform the employees of its financial situation.
There is a concept called "fidiciary duty": A manager (CEO, whatever) has a duty to THE COMPANY to ensure that THE COMPANY survives; just as a person's survival instinct is a driving force. A manager who ignores making money to appease the employees is ignoring this duty, and endangering the longevity of the company. OTOH a manager who ignores employees by forcing the money issue even when it will hurt the company (either by being a bad business decision or losing employees which are valuable) is also ignoring this duty.
Its a fine line to walk, but ultimately you need money (from shareholders) to make money (from customers) to pay money (to employees).
End of Ecnonomics 101.
You have to bear in mind that MS is a public company, with a responsibility to share holders: making money. The DoJ/MS deal is not about punishing MS for past offenses, but about bringing MS in line from this point onwards. But it still has to bear in mind that MS must be allowed to act as a business.
While I appreciate the sentiment in your comments, I feel some are an overreaction, verging on a penalty. Forcing MS to disclose its APIs, formats and protocols in advance of their publication is not going to happen; from a purely economic point of view it will be laughed at by the judge, let alone the implications on MS's rights to trade.
It would be reasonable to force MS to disclose this information AT THE TIME of publication. This does mean that MS will be ahead of the rest of the market, but that is NOT the problem! The problem is to disallow MS from preventing the market from "catching up".
If MS brings out a new product with new formats and protocols, it will attract some attention from the market. Within a few months competitors will have compatible products, so the bulk of adopters will not be forced down the MS path.
Regarding Office suites, there are several competitors on Windows, including Corel and Lotus.
As for prevention of using 3rd party components, this is a difficult one to justify. While there is no doubt that MS could circumvent requirements in this manner, such a limitation would force MS to use only open standards. Although I strongly support open standards and wish MS had to use them, it simply does not always make good business sense to avoid patent-encumbered technologies.
Please realise that any submission to the judge needs to have some level of balance. Recommending ridiculous or unworkable 'solutions' will not assist, and will likely get your comment into the ignore pile rather quickly.
IANA civil engineer, but I have spoken to several on this topic. And with no due respect, you're wrong :)
Every building is a new and unique challange, and the building environment changes far more than people may assume. An American engineer with 30+ years of experience in sky scrapers will be lost trying to build in London (where soil densities and high water table screw with foundations), Japan (where the buildings must resist regular earthquakes), South Africa (where steel-based structures corrode within a matter of years) or Paraguay (can you say "logistics").
Making a C compiler from the GCC source? make depend ; make. Or do you mean looking at the source and creating a whole new C compiler? That's not exactly a good parallel - that would be like looking at the WTC before Sept 11 and taking notes, and then rebuilding it. Not gonna happen.
The equivalent of rebuilding the WTC from blueprints would be to have the annotated design for a C compiler, including full object hierarchy, API and behavioural specification. Now give it to a programming team and tell them to implement.
Oh, one more thing. I want a more streamlines version of the WTC for thin clients. Please take out the central support columns because they are resource-intensive.
Very true. I was engineer/manager on a 9 month long project, and we hit our targets perfectly (except the last, because the company liquidated ... ack!). My team and myself were familiar with the technologies involves, and understood the requirements, which is important.
Recently I calculated it would take two weeks to port some synchronization abstractions from Windows to Solaris. I was our by 50% because Solaris pthreads implementation is broken (wrt. recursive mutex locking) - a little-published fact that took several hours to prove (that it wasn't our implementation), and days to correct.
As a matter of habbit I build in 50% buffer time if I am mostly familiar with the concepts involved, 20% if I am absolutely certain, and 100% otherwise.
And the reason this doesn't happen with bridges? The engineering team starts with a meeting of the financial backers, planners, marketers and artists. The have a mockup (drawing and miniture model) of the bridge before they start the design work, so they know that the look is agreed upon, and the idea is technically feasable and likely to be within budget.
It is often that I read knowledgeless prattle on Slashdot ... usually only from fellow commentors. This is not a troll, it is serious criticism of an article that is blatently wrong. Let's examine Mr. Oram's discussions of P2P ...
Did Universities try to stop P2P? Napster, certainly. Probably many other file sharing systems too. Why on earth would they do that? Bandwidth, security, liability. I'll elaborate later.
Mr. Oram asserts that P2P is a great way to overcome limited resources. Then expounds on how Internet2 and IPv6 are going to remove the resource barriers to P2P.
Is P2P new? No. IRC's DCC extensions have been around for at least 8 years; ytalk is even older. The idea of dsitributing information on a whole lot of servers without central control is, surprise surprise, the basis for the Web. P2P simply involves direct communication between clients, at most using a server to mediate discovery.
I'm going to ignore the anti-DMCA dissertation, because its been heard before. It also has nothing to do with P2P; just a few specialised services that use P2P as a means to swap copyright information. If it wasn't for people like Mr Oram confusing P2P with specific P2P applications, then P2P as a whole wouldn't have a bad name.
A little later we hit the "IPv6 will help" argument, to which I can only say: security. Sure, you get rid of NAT. But at the risk of placing your device in the line of fire. Even if it is "secure by default" (so end users don't have to worry too much), it is still accessible from everywhere. That means DOS vulnerable, attack vulnerable when a security hole is found, and each and every individual is responsible for their own security. That doesn't work in corporate of group/organization networking. A central point needs primary control over security for the entire network. NAT, firewalls, and prevention of arbitary data coming IN to the network unsolicited are significant defenses against attack.
Which brings up the strongest point for universities to deny P2P: they would have to allow access to P2P services (yes, P2P is actually a client and a server on each machine) behind their firewalls, causing a security risk. Typically universities have a limited number of computers providing services behind firewalls, and take care to guard them against attack, and quarantine them in case of breach. With P2P, this approach goes out of the window.
For the same reason Mr Oram has ignored the security communities hatred of SOAP, a protocol explicitly designed to penetrate those nasty firewalls that administrators put up. Tell me, why don't we just set up a public inbound IP-over-TCPIP tunnel available on all firewalls so that we can get past them?
Now Mr Oram turns to debunking the security argument. Totally missing the point of course. You can encrypt and sign until your CPU is blue in the face, and still have zero security because your computer has been compromised. Unless you can adequately secure ALL services on your computer, you are insecure. One of the best ways to secure a service is to shut it down. The more services, the more ports of entry. Not surprisingly, P2P is a service.
Sendmail and apache serve massive amount of network traffic every day. They have taken years to mature to a point where they are mostly secure, yet new hacks are found for them every so often. How long until P2P implementations reach this level of maturity, and security?
The McAfee example is laughable, to say the least. Multitier client-server technology isn't P2P, not matter what this supposed expert wants to believe. Oh yes -- what was that announcement two weeks ago about an attack on the McAfee auto-upgrade feature?
While most of the assertions regarding bandwidth are true (shock!), Mr Oram is WAY OUT on the University issue. You see, students may be downloading the same amount irrespective of whether they use P2P or FTP ... but there is the issue of UPLOADING. Having administered a network for just a small company at the time of Napsterism, I saw a massive increase in bandwidth use just from Napster fielding and responsing to queries, even before local users started downloading the music.
Finally we conclude by returning to nonsense: Seti@home is P2P?!? In what universe does distributed computing offloaded by a central server and in which none of the computing nodes communicate with each other get classified as P2P?
Please, Mr Oram. Understand at least the vaguest basics of a topic before spewing garbage about it.
[Start Flamebait] Please would the moderators have some knowledge of the topic BEFORE flagging things as "Interesting" or "Informative"[End flamebait]
XML solves the data format problem, and nothing more. It does not solve the interchange problem because apps still need to know where to locate relevant information in an XML doc, and how to interpret it. i.e. they have to have knowledge of the DTD and translate from the XML (structured according to the DTD) into their own internal format.
So instead of needing to create a reader for a binary EDI format, you plug in a bog standard parser and get named values. So it makes interchange EASIER for the programmer. Especially those with languages that don't do binary data very well.
God only knows what XSL has to do with "programming language design". XSL has two explicit goals: 1. (XSLT) a generic translation from one XML format to another. Why? Because everyone wants to use their OWN XML DTD, so to interact with umpteen other products you need to understand the DTDs of each ... or you write an XSL for each to change it into your format. 2. (XSL:FO) display primitives to allow an XML document to be transformed into a display language, so we can see the damn thing.
This is not only about trust; it is about economics. Small development studios representing a single owner, or a partnership, produce a vast amount of software for the Internet. OpenSource development teams likewise have no corporate presence, and rely on the identities of individuals.
This may sound like an innocuous move now, but consider the general direction of the intellectual property movement. The only way to truely secure digital content is to tie it to an identified user. That means hardware capable of decrypting content on the fly using a user-specific key. It is unreasonably difficult to reencrypt each piece of content for different hardware, so a license certificate is used to associate the content key securely with the user's identity.
CPUs already exist to do this for secure computing applications, and its hardly improbably that Intel and/or MS have considered this as a route for development. Whether it is the hardware or the OS that enforces it doesn't matter awfully much: at some point a corporation is responsible for issuing a license certificate which will marshall the association between your software certificate and a user's identity certificate.
In other words, someone has the power to determine if your software is allowed to run on their hardware, or not. By denying you a developer certificate, they can prevent your software from running.
Right now that's not a reality. Unsigned code isn't prevented from running, it just causes a miriad of warning and threats which most users will back away from.
So the moral of the story is be a big corporate, pay lots of money, and your product will be used. Otherwise you're sleeping in the sewer, my friend.
Twylite
Hmmm ... I must be missing something. Thawte does not require developers to present their passport or drivers' license in person. They get the details and check with the records of the appropriate authority; there is no physical interview, no cross-check that you aren't quoting someone elses details. If you have their name and numbers, you can masquerade as them.
Companies? Pah. Give me R250 and I can buy a close corporation with a name, registration and CK number (this is in South Africa, btw). It doesn't take a genius to get a corp. certificate from there. If you have the $200 for the certificate, it shouldn't be stretching finances to find the additional $30 for the corp.
Oh ... there's still no-one who is going to check that the company represents the people it claims to...
IANAE (engineer), but I have spoken to several in the wake of the attacks. Apparently the US is one of the few countries to use steel as a basis for the superstructure of skyscrapers. In many parts of the world it is simply not economically or physically viable to build in this manner.
For example in South Africa (in coastal regions) it is not unreasonable to expect the highest grade of stainless steel to corrode within 5 to 7 years. London I am told has similar problems given their summertime humidity, a problem shared with many Pacific Rim locations.
While buildings not built in this manner (steel superstructure) would be more resistant to fire, it is difficult to speculate on the outcome of such an attack. Most likely the building would not have collapsed, but would have been considered unstable beyond a certain floor (and the entire structure demolished and rebuilt).
The main thing that distinguishes Rebol is a tiny footprint, and ground-up design for interaction in a networked environment.
Technologically, you have no clue what .NET or Java are about. Java by virtue of syntax and documentation is probably the simplest of languages around, and both .NET and Java run as bytecode on interpretters.
But most important, Java (and to some extent .NET) is significant for real-world enterprise applications because it defines specifications for interoperability. J2EE is not about providing programming libraries; it is about providing standards.
Rebol falls flat on this count in the same way as every other programming language: you have to lock yourself into a vendor at API level, not at language level.
A history that began when another "religion of peace" said 'Hey, let's slaughter these godless bastards'.
Hardly a way to find out their true way of life, is it?
in the interest of world security? No. In the interests of Western security? Yes.
The US has refused to engage in disarmorment programs along with the rest of the world, and it will not allow UN weapons inspectors to view its stockpiles. Yet any other country with nasty toys must give them up and be at the mercy of the US.
3) ... perhaps the US should have withdrawn its troops from Saudi Arabia in line with the requests from various Middle East countries, and Bin Laden's demands for the past 5 years. Especially since they have no business being there anyway.
Of course no-one can say for sure whether this would solve the problem, but a willingness to negotiate is essential in resolving conflict in a non-violent manner.
A concept which America has shown itself incapable of grasping.
The US is withholding Free Trade from Iraq. It has not allowed any other member of the world community to decide independantly how they wish to deal with Iraq: if a country does not ceed to the US imposed sanctions, it too faces sanctions from the US.
Innocence is subjective. As is terrorism.
America is bombing a nation that has supported terrorism against America. It does this after imposing sanctions against a country allied to that nation, sanctions that are causing slow death as millions starve. This act forms part of the motive for the terrorism against America. In bombing Afganistan, America is inflicting further civilian casualties.
Where is the respect for human life? America is as much to blame for murdering innocents as Bin Laden or the Taliban. Yet few people see it this way: economic sanctions, although often more crippling than all-out war, are socially acceptable. Bin Laden struck at the heart of America's economic power; an 'appropriate' response to abuse of that power.
Terrorism comes in many forms.
The way I understand this, you have old clients, new clients, and a server that must handle both. And the server and new clients should support Unicode.
First, although this is probably obvious, I should note that if your data is primarily text, then you're looking at a 2Tb database when you start using Unicode (depending on the encoding).
This is sortof like supporting German language entry, and wanting to display it on English clients. Its not easy, but it can be done, to some extent. Most Unicode you encounter will have an equivalent ASCII representation; there are acceptable conversions for almost all non-Eastern character sets. You can serve up a converted representation to your ASCII clients.
DO NOT listen to the bullshit about serving up UTF-8 to ASCII clients. They can't understand it any more than I can understand German ; it will seem to work only for low-ASCII characters, but break for all others.
As for data validation, you are going to have to have two rulesets. One will be client-side ASCII; the other a unicode ruleset used by both the new client and the server. Incoming ASCII from the old client should be converted to equivalent Unicode (that's the easy part) before being validated.
Sorry, no realworld information here either ; certainly not on database that size.
What's with people assuming that UTF-8 is ASCII? Its not. UTF-8 is a multibyte representation, that just happens to coincide with ASCII for characters 0 through 127. After that it takes two bytes to encode a character, possibly more when you get to "big" characters.
UTF-8 is an encoding for unicode characters.
A lot of civil liberties proponents lose the plot at some point, and viciously attack any attempts at monitoring or interception. While I'm all for screaming blue murder about wholesale invasion of data and privacy, there is a point at which the state investigatory power that be require legitimate access to communications.
No, this would not have stopped Bin Laden & co, who communicated in public. Nor will it stop many related activites. But it is extremely effective against fraud and crime syndicates. I come from a country where these crimes are rife, and most convictions follow some form of search warrant.
The dividing line between good and bad is the inclusion of the court system into the process. Courts can already give permission for physical searches and wiretaps, subject to the provision of prima facae evidence. This is good.
Enough evidence must exist to convince a court that there is likely to be a crime, and that a particular person/group is likely to be implicated, before such a warrant will be issued.
There should be no difference for digital communications. Wiretaps could be used along with equipment to translate the wire signal into packet data, but this is inefficient. Just a telecoms companies are obliged to cooperate with the police (FBI), so ISPs, arguably the carrier for TCP/IP based data, should be obliged to cooperate (although not necessarily at their own cost).
When it comes to encrypted communication, the lines blur a little more, but only a little. You can be prosecuted for refusing to acknowledge a search warrant, or for refusing to testing (except in cases involving the Fifth Ammendment; and many countries don't have an equivalent), or for withholding evidence; so you should be able to be prosecuted for not providing the cleartext to an encrypted communication and, if necessary, proving it is a decryption of the ciphertext.