Windows here suck the most. NTFS is good, but all the backward compatibility cruft just drags the FS down.
Once under Windows, I have spent about half an hour with Explorer refusing to copy one one. Explorer was insisting that "File No Found". Text file was there and perfectly editable by notepad. I needed about 30 minutes to observe that Explorer was giving error on only on file of whole directory and that file have had the longest name. ZOMG!!! They still have cap 255 bytes on path(!) length!!!
Welcome to 3rd millenum, Microsoft! Where do you want to go today?!?
End-Of-Sarcasm.
Realistically, I never had a single problem with Mac or Linux when handling file names. But when you get to Windows, you start getting the annoying messages from explorer "invalid character" with attached long list of characters they do not allow to use. All the time. And I'm not talking about bunch of non-Unicode applications (for example Adobe Acrobat Reader) which cannot open file with name containing international characters. Could it be any dumber?
Application layer proxies in the firewall world refer to intelligent proxies that do protocol inspection.
I do not want to go into the depth, but any protocol recognition/etc is already intellegent. And after some time spent in industry, you would have known that there is no such thing as "intelegent proxies". It's all PR myth. What they really do is look at TCP/UDP port numbers. Nothing more. And there is nothing else you can actually do.
Simple example some time ago used to crash experimental demo of such system. First line of TCP stream looks like "GET / HTTP/1.0". What protocol could that be? The answer isn't trivial as many might have thought. It might be (1) HTTP protocol, (2) FTP data connection receiving text file containing HTTP dump, (3) It might be Skype probing for transparent HTTP(S) proxies and so on. There is no way you can analyze it intelegently. All the methods have holes.
In my case it was even more problematic. Telcos/celcos wanted to use that for quality of service and charging. E.g. if you connect to www.o2.com - it's free, if you go to www.t-online.com - you pay $XX. But they are still not reached the magic number of 85% of properly classified traffic. Not yet. As soon as you find out that you have such equipment installed, simple countermeasures like proxying and encryption will get you off the hook.
P.S. Biggest problem with such analyzers, that they cannot look into encrypted protocols. Even BitTorrent started encrypting traffic to avoid dumb packet matching.
P.P.S. Another interesting situation arises from dropped TCP connections. Was it legit connection? Or was it not? Has anybody received anything or not? Many intelegent accounting systems can be bypassed by tuning OS to *not* to close cleanly TCP connections. Not good situation too. If you are not on receiving end - no way you would know what was happening.
Application layer? That's would be HTTP, FTP, BitTorrent and any other internet protocol running over TCP/UDP. In other words: anything. Also try to remember that "application layer" as specified by ISO's OSI has little/no relation to reality. (Which layer is SOAP which runs on top of application layer HTTP? Which layer is protocol using SOAP? That's why they are called "network stacks". Real world hardly fit into 7 layers of OSI.)
It is a rare project indeed that truly requires hard deadlines. Smart clients and smart development shops will reach a more flexible arrangement, and come to respect each other for having realistic expectations and providing realistic updates as time goes on.
You are out of reality. I have never seen such close relations between developer and customer companies. (Uhm, okay, once: when our customer had no money available to pay for work already done.) It's just impossible to make such a flexible contract which would guaranty fair conditions for both developer and customer. Impossible.
I cannot speak for management, but from my developer's pov the are really few options. Working under pressure of schedule is least pleasant task, especially when company's existance depends on the delivery on deadline. In such situations (I was facing them twice in last 5 years) I prioritize my tasks on future reusablity.
In one case, I did lots of work to automate and document process. I made software work on its first deadline. The question was what company will do after i am gone. Company's hardware department missed deadline - software was "ready" (as much as software can be ready w/o hardware). I documented all stuff and then took safer option looking for better places to work. Management completely missed complexity of hardware platform. Software complexity was mitigated by my experience - hardware guy has never before developed PCI product and went from plain engineer to layout designer in under two years. But still working hardware was about one year away. There are no miracles.
In second case, telecom start-up, meeting deadline was impossible. The software team decided internally to go on with development which can be potentially useful even if start-up would bankrupt. Minimum dependencies and high portability. Start-up was not able to find money to continue product development and was eventually sold out. The work software team did just before bankruptcy wasn't wasted: it works even now, under different name in different company located in the ex-office of the start-up, stuffed mostly with the start-up core members. But it works. I'm not there, but when I meet ex-colleagues still working there, they always bring topic that some pieces I made are still still work, still in use and new things get developed on the foundation.
My morale would be that when faced with impossible schedule, try to develop personal realistic plan and go with it. Put on plan what is easy for you to do and what might be useful for scaled down schedule. Pressed with deadline, schedule might be reworked and scaled down to include fewer features - try to guess what might be on that minimized schdule. And go with it. It's impossible to cover everything - but learning to grasp essence is necessary. That comes with experience.
Also, no good company/management would force its workers to do impossible. If they are not good - then changing job might be better choice.
We all can only speculate. But my bet wild guess is quite simple. In the whole existence of Internet, there is no other internet service subjected that much to abuse as eBay. It's just not a fanny place to experiment with new stuff.
From my personal experience, any newcomer is always prone to abuse: service has no strong user base, has no well established identity, rough edges in service and so on. Especially Google Checkout since as many have pointed out it's jsut a gateway to credit card. And CCs are *last* thing anybody would considers "safe" and "prone to abuse." In fact that the prime reason why Europe at large doesn't use CCs - but instead safer Maestro cards. ( http://en.wikipedia.org/wiki/Credit_card vs. http://en.wikipedia.org/wiki/Maestro_(debit_card) )
I definitely do not want to see tomorrow news story about scam on eBay involving fake Google Checkout. Nor does want eBay nor Google. As Google Checkout will mature, I'm sure another day it will provide the same level of safety and integration with eBay as does today PayPal.
I have sent question to Apple's support about ODF support but got no response. I was really thinking about buying it - after pains of OOo on Mac OS (and not only Mac OS).
In the end, you have to recall that M$ own share of Apple and they have some sort of agreement. As long as M$ itself doesn't support ODF officially I'd expect Apple will not move a finger. What is rather sad reality.
None of that $200 has gone to the artists, it's all gone to Russian criminals. And you're happy with this?
I came to shop and cashed out €18 for old Queen's album The Works. How much of that went to artists?
€5-7 is retailer's fee. about €10 is label fee. So how much went to artist? I wonder.
See, the industry is actually only interested in people paying money for music if that money is going to the industry and the artists.
[ You really seem to work for RIAA/whatever. You speak too well. Or if not, talk to them - probably they are hiring now for astroturf campaing. You would fit. ]
The point here is that people want art on their conditions, not on conditions of labels. It's simple as that. And at moment there are no other ways to easily buy music. Read any review on how subscription model works in real life and what kind of PITA it can be. (At least for some people Apple's iTMS kind'a works - better than nothing).
Just try to get that in your head: it's not about money, it's about music. It's not about industry - it's about art and music. Ring any bells?
I think the all story with "recorded music" is just bluff. Now how do I understand the russian copyright law. The law is quite simple. The performace is what artist is paid for. I can record the performance and (granted that I have paid artist the fee for performance) I would own the recording I did (with copyrights etc). It's my recording of her/his performance. I can make money selling the recording. Artists can go on doing money by performing. It's easy as that. Nobody is robbed, as RIAA/BPI/IFPI/friends try to tell everybody. Artist has to pay taxes from the profits s/he makes performing. If I would be distributing recording, I would need a license for that from gov't and of course I will pay taxes too. (*)
As much as idealistically it sounds, I think such model can work: only way for artists to profit is to perform. Not like the starlets a la Britney Spears, living off huge promotional and ad campaigns. They have to perform. No performance - no money. I think it's even logical.
In the end, as live music fan, I can tell that in reality that how it is works. Recorded music is in quantity - but it will never beat the quality of live performance. All best music I ever heard in my life was in Dresdner "Blue Note" cafe sitting against musicians play live jazz.
(*) I hope I did not infriged your copyrights for quoting *your* words in *my* comment? Or would you sue me for that??
Innovation is hard, that's why so few companies do it very much.
There also appears to be an optimum size for innovation. If an company is too large there tends to be a corporate culture against risk taking, even if the actual level of risk is not that high.
In my experience, larger company gets, more interested people are involved in development loop. More people - more critics. Bright ideas just die under weight of what-ifs. Or people (like me) just stop proposing new things - just to avoid confrontations with others.
And that's precisely what happened with Vista (The World As Best As I Remember It) When you have meeting with 11 managers - you would think thrice before spitting anything out. I had experience of meeting with 4 managers on the table - and that was very unpleasant. Everything you say have to satisfy everybody. Or meeting will never end, since everybody want their way of things approved.
As many insiders have spoke up, the office division to date mostly avoided the fate of other products developped in Redmond. The goals doesn't seem to change much - no innovations really needed. But M$O2k7 looks to me precisely like product made "for a change," rather then to satisfy some need. With grain of sarcasm, I might notice that maintenance of infamous upgrade spirale is the real need behind that M$O release.
Yes. Organizations lobbying for particular laws do lobby for their own sake, not somebody's else. On paper, the function of such gov't bodies always sounds great.
Real world example. In Germany there is GEMA which does precisely what described in article. And more.
To receive compensation from GEMA you have to register there, pay fees, do lots of paperwork and have kind'a stable release schedule. In the end, only big labels can afford to register and support their artists there. No big surprise. Of few local indies I know, nobody is registered. And there lots of stupid fees all over the place. E.g. every stage has to pay for any kind of concert it has fee depending on size of hall; every place playing some music has to submit their programing to GEMA. And so on.
It's [CENSORED] up system.
More info is here . Unfortunately, English wikipedia has no information. Despite wikipedia's stance on neutrality, critic of GEMA takes good part of german article. The service GEMA does controversial at best.
Majordomo.ru hosts many free mail lists. It sends *large* amounts of e-mails daily. There were many attempts to curcumvent the service and use it as spam relay. Probably some of the attempts succeded to some extent. Most probably, the spam black list service just got them once N years ago listed, and never bothered to contact admins / resolve the matter. Admins over there are quite responsive.
RedHat listens only to its customers - proportionaly to the price they have paid. Ubuntu still listens to its fellow users.
RedHat would score all enterprise contracts and might replace M$ in its role of "single OS vendor" with all consequences. Ubuntu (as well as Debian) would score all grass root deployments.
I already had experience of RedHat in office and Debian at home. IMHO RedHat, as it is now, is already good replacement for Microsoft: unusable default installation, updates break things, no proper application versioning (CVS200X0Y0Z1030 is NOT a version number), etc. On other side Debian... is STILL just WORKS. As it did all along 7 last years.
while keeping prices artificially high in another through legislation
Hardly can disagree on any point made. Thou quoted above is necessarily true. I would say nothing about U.S. - but I can comment about Germany where I live.
After countries of estern block have joined EU, something similar started happening over here. And even more radical: there is no such wide cultural gap between e.g. Germany and Poland as there is between U.S. and India. Business started dumbly moving work from West to East. In Germany on average employee costs about 3-5k Euros. In Poland you can get "best of bread" for about 2k, while prices for middle/low level specialists can be as low as 500 euros/month.
When you look at how the money - 5000 in Germany, 2000 in Poland - gets distributed, you start understanding the real difference. From 5k euros, about 2k consumed by social system, another 1k consumed by all kinds of mandatory insurances. Substract cost of living and you get 750 - all I get on my hands. Ironically, specialist from Poland would get the same cash in the end. It's just Poland doesn't have pile of mandatory insurances, it doesn't have fat ugly over-abused social system, it doesn't have such high taxes required to run such complicated and expensive tax system.
In the end, it comes down to populistic measures (like improved safety in social sector) used by politicians to boost ratings which in the end hits back in shape of new taxes at people who voiced and voted for it.
[Offtopic];-) I haven't noticed your nick.[/Offtopic]
To the practicalities. Use case. My company. We switched recently to SVN. Pilot of SVN was - any guesses? - documentation repository, filled with WinWord and OOo documents. We have adopted OOo for internal documentation about 3 years ago - some time after 1.0 release. (M$O files when open from networked drives gets corrupted often - sad reality).
SVN + OOo are good friends.
SVN supports well binary files. That's for first. (As opposed to patch centric decentralized systems: you can't diff binary files).
Second. SVN has nice feature: "require-lock". Once that flag is set on file, the file would be checked-out as "read-only". OOo notices that and opens file read only. (One can only dream about such function in M$O: opening files in read only/viewing mode.)
If one wants to modify file, he has to acquire lock. That prevents two people working on the same document simultaneously and also protects file against possible accidental changes. Overall, we yet to run into any serios problem with the combo.
The major downside is mentioned elsewhere: you can't diff (and OOo support for changes is at best buggy). On other side, since that's commercial company (we do not have redundancy of distributed development model): only one person is charged with working on particular document at any given time. And changes must be filed separately in the (now in SVN) revision log.
P.S. The unavailability of diff, can be somewhat offset by internal OOo's versioning. Thou normally you can't expect to have OOo's version for every SVN's revision.
And the best of all is that its not stored on some obscure RAID-less laptop somewhere. Instead it is stored on that secure, central server which all developer teams need to have. If you don't have one yourself, there are some Subversion hosting companies.
What are you smoking? If you went off to sightseeing - trees, rivers, nature, etc - iow no internet. Or your favorite Cisco router died during OS upgrade. Where are you going to commit to????? By "disconnected operation" I meant precisely that - "disconnected operation". With SVN you are out. With Arch I can still work localy and commit localy - having all my changes the way I like them. That's for first.
Second. You did N changes in my-experimental-branch. Time have come to bring the changes onto the trunk. What happens with SVN? All N changes will be lumped together in huge blob called "merge". With decentralized systems, trunk will receive from my-experimental-branch N patches + possibly one more additional patch to resolve conflicts. All changes are there - with all info attached. With SVN that info is not there: only way to see it - is to guess where from the original changes have come. Few month down the road it might be not that easy to guess which of the my-experimental-branch-001234/005678 was the source of the merge. The difference is that branches in SVN are completely independent from each other. In systems like Arch branches are nothing more than set of patches: they can be combined - the point of forking can be easily found by looking at the list of patches in the branches.
Third. Not every SVN repository allows everybody to create tags/branches. What's quite good practice - tagging and branching in centralized systems better to be done by dedicated repository admins. We have in office about 2.5k branches - and I know the pain of managing that mess.
To conclude: you need to try decentralized system - e.g. GNU Arch or Darcs - once. (Darcs is quite straightforward and easy to start with, compared to both GNU Arch and BitKeeper.) I also have had problems getting all the differences between classical CVS-like systems and newer Arch-like systems. And read SVN book once more - it's good - just to understand what/why SVN can and cannot.
I have read once BlackDown.org's license. The license is flat out prohibit redistribution. End of Story.
From the mail lists, my impression (developers refused to discuss directly the contract with Sun under which they do port Java to Linux - they seem to be under NDA) was that most of the restrictions came from Sun, not from BlackDown people. Debian cannot give you BlackDown's port of Java, you have to go to BlackDown.org to get it: that's part of license.
And now it seems that Sun's JRE/JDK license has the same problem: it prohibit redistribution. Or as I have understood from the discussion, it attach conditions to redictribution, making Debian (and consequently SPI) legally liable for potential damages. Getting Sun's JDK from Debian and getting Sun's JDK from Sun are two _legally_ different things. As long as restrictions there, no way (even in non-free) such package can appear. Sun's people reacted and said they will fix the problem with license. We just need to wait couple of weeks to see what will come out of that.
P.S. Try to imaging your position as Debian Project Leader (DPL). You have responsibilities. In fact you are responsible for all decisions made during the time you are in power. Someone (behind your back) includes package with long list of restriction into the Debian. And then company whose work got included sues SPI for damages from illegal distribution of the software package. SPI would of course blame responsible - not the guy uploaded the package - but project leader, DPL. The Debian policies exist to avoid such situations - to avoid needless legal risks. You just can't ignore them, because you potentially jeopardize others.
The U.S. has the "best democracy money can buy" (c) whoever said it first.
I think, somebody there over the pond, has to start a case against gov't: the executive branch become so obese, that only voice of big wallets can really reach it. That's discrimination against normal people who cannot represent their interests (iow cannot buy good lobby) as good as big business can.
As it looks from Europe, you have basicly three lobbying groups for every branch of law: big business lobby, medium/small business lobby and independent lobbists. Big business buys another law by making a pact with medium/small business lobbies. Independent lobbist are of course left off board. I cannot stop myself thinking that this is conduct anti-trust law designed to deal with.
Sharing is an inherently centralized process anyway (Whether it happens on a central server or through some peer mechanism is irrelevant, it's centralized on you putting it the same kind of place someone else looks for it)
You got it wrong. Or got only half of it. Sharing is a double edged knife: it can hurt as much as it helps.
To explain it simply, decentralized systems allows me to have local intermidiate version of file. In centralized system, if I want my changes be protected or simply numbered (so I can rollback later), I have to commit working files into repository.
If my changes are at very very early stage and not yet ready for general use, commiting would force others to do additional steps to avoid using my new (raw, broken) version of file. If there are many commiters like that - and that's pretty normal with huge source code repositories - the life can easily become nightmare. (*)
Decentralized version control allows you to have local repository. And consequently, it allows you to commit you changes to your repository. It doesn't forces my changes on everyone before proper time X, but allows involved people to pull changes directly from my local repository and for example to test their own changes along with my ones.
When time comes, I can submit all changes from my local repository to global public one.
P.S. Another good use for decentralized version control, is disconnected work. If you are with your notebook in office - you can commit. At home - with centralized repository in office - you can't. With decentralized system - you can commit directly on your notebook, and later on when reaching office, commit changes from notebook made over week-end.
(*) That's the reason why in centralized systems, changes are very big - people tend to commit less to avoid needless breakage. In decentralized systems changes are often small and abundant. You can afford the luxury.
OpenDocument is XML + Styles + etc stored in single ZIP file.
If one can teach OOo to work with unzipped directory as if it was OpenDocument file, then answer to your question would be "yes".
At moment the answer is "no".
P.S. Thou, OOo can preserve multiple versions of a document inside of document itself. "File" -> "Versions...". I'm slowly teaching our documenters to use that thing and preserve all public releases of documents with OOo versions. Not as good as diff+svn, but still something very useful you can't do with M$O.
P.P.S. Mac OS X has funny concept of "bundles". Bundle is basicly directory with some application assigned to open it. As user concerned, it behaves just like file. For example all applications in Mac OS X are bundles (and e.g. application icon is just file in prescribed location in the bundle). Since Windows/GNOME/KDE do not support such stuff, the chances of the support in OOo are very slim. W/o proper support in OS, handling of such bundles for average user can be very burdensome. As another good and closer to on-topic example, MacOSX uses bundles to save RTF files with embedded pictures: inside of bundle one would find rtf itself and all images rtf references.
Would be bundles supported in all OSs then zipping would be needed only to send files across net.
What you smoking? M$ never shipped PDF support with any of its applicaitons.
Adobe Acrobat Reader (and in some case FoxIt Reader) is the standard item on all installation lists - lists of non-M$ software required to make M$ Wind0ze any usable. It's just like WinAmp or iTunes for MP3s.
PDF is standard. Period. Do we like it or not, more or less all industries I have worked with preinstall Acrobat Reader on all computers. It's less relevant on home desktops - but as soon as you get any documentation for a device you run into the PDFs.
M$ will have to challenge what people like most in PDF: stability. No, it's not quality of print nor performance - it's stability. Do I like Acrobat Reader or not, I still can open any PDF created many years ago w/o any problem. As time had showen, M$ has problems with long-term commitments. If they will manage to keep Metro afloat for 8-10 years - the time it took PDF become standard - then it might become new standard. Not sooner.
P.S. [Sarcasm] The only way for M$ to make file format which will last that long, is to make it very very very bad. So that to fix all the problems of the version 1.0 and to release version 2.0 they would need a decade. Just like it happened with WinNT to Win2k transition (that took 8 years, NT4 delays included). Thou I can hardly imaging something worse than WinNT 4.0. But M$ is definitely capable of surprising us. [/Sarcasm]
Security clearance is nothing new. Nor it is indicative. Case: DVD/CSS v. DVD John. CSS was secret just because is was easy to crack.
On-topic. Sounds as good idea. Let's just hope that secretive implementation wouldn't hold the evolution of the system. Good sign would be a competition - both hardware competition (devices from multiple manufacturers) and content competition (programming from different providers). If they will try to hold everything to single company - then I think two years later the service would suck. As it always does when there is no competition.
P.S. One of embedded Linux system I developed was booting from flash in under 10 seconds. With 7-8 seconds out of 10 eaten by Phoenix BIOS.
In most other languages, I have a choice how to link to ActiveX. And I can avoid it altogether.
For example, some applications I have ported from VB have to use ActiveX for some functionality (wierd serial protocol used in target application field). In C/C++ people (can and do) load the library and request needed interfaces. Can you do that in VB? - No. But that's precisely what was done in C++. There are several versions of the aforementioned library in use. We tested with only one version. With VB we have to install and register it as ActiveX. With C++ we just used it as normal DLL - loaded, requested functions, got interfaces and do job. In VB you can't operate interfaces directly - you are not supposed to.
But in the end you are right. Biggest problem of my ex-employer was deployment. In fact people did tests that instalation of our software package wouldn't break VB installations for that purpose. We had bought VB6 in part for that purpose - thou it didn't worked out in the end. (M$ promised backward compatibility - and my employer falled for it - but none of the VB4 applications were ever successfully ported to VB6. In fact nobody expected that porting would be needed, since M$ claimed "backward compatibility". Always sounds good.) And still at least once per month we were getting complain about something ending up broken. Until I rewrote all the applications in C++.
First. Perl allows you to build version checks in to the scripts. It's just nobody bothers. Also quite normal practice for Perl to ship all required modules with perl application and leave them in application subdirectory. Then at run-time you can check if system version is Okay and use it. If system version isn't okay - or module isn't installed at all - application defaults to use it's own internal version. (*)
Second. ActiveX components are global and referenced by GUID. You can have two/more different versions of the same library in the system. But only can be registered at a time - only one would be used by *all* applications. Your system has library A of version 1.0. You install new application and it installs the library version 1.1 and register it. Any application dependant on behaviour of library version 1.0 would break. Worse case, is that many libraries miss versioning info at all - even Microsoft own ones.
Third. Easy start. Cheap programmers made many people happy. On one side. On another side there are people like I am. It's not that I - as system programmer - feel any competition of VB users. It's just they often make promises they can't deliver on (with software it's easy to underestimate complexity). Then customers have to run to some hardcore programmers like I am and beg to fix the system overnight since deadline was yesterday. It's not very pleasant situation I was finding myself several times.
I think for easy application development people has to use specialized systems. Consider M$ Access for data bases. Consider LabView for scientific applications. Consider Perl for text processing. Consider PHP for web applications. Consider Python for portable simple GUI applications. Almost every application field has "standard" tool which allows specialist in the field to easily develop and deploy application. VB's problem is that it tries to be too universal. Bit like Java: good for everything in general, but isn't best for anything in particular.
(*) While proof-reading the paragraph, I have noticed that's the same approach Apple used with its "frameworks". The guys are not shy and freely borrow ideas from Unix. I wish M$ did something like that to end the "DLL-Hell." But seems stuff like Aero is the current priority.
Slashdot Mirror
Windows here suck the most. NTFS is good, but all the backward compatibility cruft just drags the FS down.
Once under Windows, I have spent about half an hour with Explorer refusing to copy one one. Explorer was insisting that "File No Found". Text file was there and perfectly editable by notepad. I needed about 30 minutes to observe that Explorer was giving error on only on file of whole directory and that file have had the longest name. ZOMG!!! They still have cap 255 bytes on path(!) length!!!
Welcome to 3rd millenum, Microsoft! Where do you want to go today?!?
End-Of-Sarcasm.
Realistically, I never had a single problem with Mac or Linux when handling file names. But when you get to Windows, you start getting the annoying messages from explorer "invalid character" with attached long list of characters they do not allow to use. All the time. And I'm not talking about bunch of non-Unicode applications (for example Adobe Acrobat Reader) which cannot open file with name containing international characters. Could it be any dumber?
I do not want to go into the depth, but any protocol recognition/etc is already intellegent. And after some time spent in industry, you would have known that there is no such thing as "intelegent proxies". It's all PR myth. What they really do is look at TCP/UDP port numbers. Nothing more. And there is nothing else you can actually do.
Simple example some time ago used to crash experimental demo of such system. First line of TCP stream looks like "GET / HTTP/1.0". What protocol could that be? The answer isn't trivial as many might have thought. It might be (1) HTTP protocol, (2) FTP data connection receiving text file containing HTTP dump, (3) It might be Skype probing for transparent HTTP(S) proxies and so on. There is no way you can analyze it intelegently. All the methods have holes.
In my case it was even more problematic. Telcos/celcos wanted to use that for quality of service and charging. E.g. if you connect to www.o2.com - it's free, if you go to www.t-online.com - you pay $XX. But they are still not reached the magic number of 85% of properly classified traffic. Not yet. As soon as you find out that you have such equipment installed, simple countermeasures like proxying and encryption will get you off the hook.
P.S. Biggest problem with such analyzers, that they cannot look into encrypted protocols. Even BitTorrent started encrypting traffic to avoid dumb packet matching.
P.P.S. Another interesting situation arises from dropped TCP connections. Was it legit connection? Or was it not? Has anybody received anything or not? Many intelegent accounting systems can be bypassed by tuning OS to *not* to close cleanly TCP connections. Not good situation too. If you are not on receiving end - no way you would know what was happening.
Application layer? That's would be HTTP, FTP, BitTorrent and any other internet protocol running over TCP/UDP. In other words: anything. Also try to remember that "application layer" as specified by ISO's OSI has little/no relation to reality. (Which layer is SOAP which runs on top of application layer HTTP? Which layer is protocol using SOAP? That's why they are called "network stacks". Real world hardly fit into 7 layers of OSI.)
You are out of reality. I have never seen such close relations between developer and customer companies. (Uhm, okay, once: when our customer had no money available to pay for work already done.) It's just impossible to make such a flexible contract which would guaranty fair conditions for both developer and customer. Impossible.
I cannot speak for management, but from my developer's pov the are really few options. Working under pressure of schedule is least pleasant task, especially when company's existance depends on the delivery on deadline. In such situations (I was facing them twice in last 5 years) I prioritize my tasks on future reusablity.
In one case, I did lots of work to automate and document process. I made software work on its first deadline. The question was what company will do after i am gone. Company's hardware department missed deadline - software was "ready" (as much as software can be ready w/o hardware). I documented all stuff and then took safer option looking for better places to work. Management completely missed complexity of hardware platform. Software complexity was mitigated by my experience - hardware guy has never before developed PCI product and went from plain engineer to layout designer in under two years. But still working hardware was about one year away. There are no miracles.
In second case, telecom start-up, meeting deadline was impossible. The software team decided internally to go on with development which can be potentially useful even if start-up would bankrupt. Minimum dependencies and high portability. Start-up was not able to find money to continue product development and was eventually sold out. The work software team did just before bankruptcy wasn't wasted: it works even now, under different name in different company located in the ex-office of the start-up, stuffed mostly with the start-up core members. But it works. I'm not there, but when I meet ex-colleagues still working there, they always bring topic that some pieces I made are still still work, still in use and new things get developed on the foundation.
My morale would be that when faced with impossible schedule, try to develop personal realistic plan and go with it. Put on plan what is easy for you to do and what might be useful for scaled down schedule. Pressed with deadline, schedule might be reworked and scaled down to include fewer features - try to guess what might be on that minimized schdule. And go with it. It's impossible to cover everything - but learning to grasp essence is necessary. That comes with experience.
Also, no good company/management would force its workers to do impossible. If they are not good - then changing job might be better choice.
We all can only speculate. But my bet wild guess is quite simple. In the whole existence of Internet, there is no other internet service subjected that much to abuse as eBay. It's just not a fanny place to experiment with new stuff.
From my personal experience, any newcomer is always prone to abuse: service has no strong user base, has no well established identity, rough edges in service and so on. Especially Google Checkout since as many have pointed out it's jsut a gateway to credit card. And CCs are *last* thing anybody would considers "safe" and "prone to abuse." In fact that the prime reason why Europe at large doesn't use CCs - but instead safer Maestro cards. ( http://en.wikipedia.org/wiki/Credit_card vs. http://en.wikipedia.org/wiki/Maestro_(debit_card) )
I definitely do not want to see tomorrow news story about scam on eBay involving fake Google Checkout. Nor does want eBay nor Google. As Google Checkout will mature, I'm sure another day it will provide the same level of safety and integration with eBay as does today PayPal.
I have sent question to Apple's support about ODF support but got no response. I was really thinking about buying it - after pains of OOo on Mac OS (and not only Mac OS).
In the end, you have to recall that M$ own share of Apple and they have some sort of agreement. As long as M$ itself doesn't support ODF officially I'd expect Apple will not move a finger. What is rather sad reality.
I came to shop and cashed out €18 for old Queen's album The Works. How much of that went to artists?
€5-7 is retailer's fee. about €10 is label fee. So how much went to artist? I wonder.
[ You really seem to work for RIAA/whatever. You speak too well. Or if not, talk to them - probably they are hiring now for astroturf campaing. You would fit. ]
The point here is that people want art on their conditions, not on conditions of labels. It's simple as that. And at moment there are no other ways to easily buy music. Read any review on how subscription model works in real life and what kind of PITA it can be. (At least for some people Apple's iTMS kind'a works - better than nothing).
Just try to get that in your head: it's not about money, it's about music. It's not about industry - it's about art and music. Ring any bells?
I think the all story with "recorded music" is just bluff. Now how do I understand the russian copyright law. The law is quite simple. The performace is what artist is paid for. I can record the performance and (granted that I have paid artist the fee for performance) I would own the recording I did (with copyrights etc). It's my recording of her/his performance. I can make money selling the recording. Artists can go on doing money by performing. It's easy as that. Nobody is robbed, as RIAA/BPI/IFPI/friends try to tell everybody. Artist has to pay taxes from the profits s/he makes performing. If I would be distributing recording, I would need a license for that from gov't and of course I will pay taxes too. (*)
As much as idealistically it sounds, I think such model can work: only way for artists to profit is to perform. Not like the starlets a la Britney Spears, living off huge promotional and ad campaigns. They have to perform. No performance - no money. I think it's even logical.
In the end, as live music fan, I can tell that in reality that how it is works. Recorded music is in quantity - but it will never beat the quality of live performance. All best music I ever heard in my life was in Dresdner "Blue Note" cafe sitting against musicians play live jazz.
(*) I hope I did not infriged your copyrights for quoting *your* words in *my* comment? Or would you sue me for that??
In my experience, larger company gets, more interested people are involved in development loop. More people - more critics. Bright ideas just die under weight of what-ifs. Or people (like me) just stop proposing new things - just to avoid confrontations with others.
And that's precisely what happened with Vista (The World As Best As I Remember It) When you have meeting with 11 managers - you would think thrice before spitting anything out. I had experience of meeting with 4 managers on the table - and that was very unpleasant. Everything you say have to satisfy everybody. Or meeting will never end, since everybody want their way of things approved.
As many insiders have spoke up, the office division to date mostly avoided the fate of other products developped in Redmond. The goals doesn't seem to change much - no innovations really needed. But M$O2k7 looks to me precisely like product made "for a change," rather then to satisfy some need. With grain of sarcasm, I might notice that maintenance of infamous upgrade spirale is the real need behind that M$O release.
Yes. Organizations lobbying for particular laws do lobby for their own sake, not somebody's else. On paper, the function of such gov't bodies always sounds great.
Real world example. In Germany there is GEMA which does precisely what described in article. And more.
To receive compensation from GEMA you have to register there, pay fees, do lots of paperwork and have kind'a stable release schedule. In the end, only big labels can afford to register and support their artists there. No big surprise. Of few local indies I know, nobody is registered. And there lots of stupid fees all over the place. E.g. every stage has to pay for any kind of concert it has fee depending on size of hall; every place playing some music has to submit their programing to GEMA. And so on.
It's [CENSORED] up system.
More info is here . Unfortunately, English wikipedia has no information. Despite wikipedia's stance on neutrality, critic of GEMA takes good part of german article. The service GEMA does controversial at best.
Majordomo.ru hosts many free mail lists. It sends *large* amounts of e-mails daily. There were many attempts to curcumvent the service and use it as spam relay. Probably some of the attempts succeded to some extent. Most probably, the spam black list service just got them once N years ago listed, and never bothered to contact admins / resolve the matter. Admins over there are quite responsive.
I think the (soon crucial) mass of artists opining on the hypocrisy of recording industry is growing steadily.
I mean, all used to consumer screams "we're reaped" and labels' flat response "it's all to compensate artists."
And it's very nice in the end to hear artists weighting in with same "we're reaped." I wonder what labels would reply to artists now.
They are basicly cornered themselves - even piracy is written off of the artist's bills.
Who would possibly win?
RedHat listens only to its customers - proportionaly to the price they have paid. Ubuntu still listens to its fellow users.
RedHat would score all enterprise contracts and might replace M$ in its role of "single OS vendor" with all consequences. Ubuntu (as well as Debian) would score all grass root deployments.
I already had experience of RedHat in office and Debian at home. IMHO RedHat, as it is now, is already good replacement for Microsoft: unusable default installation, updates break things, no proper application versioning (CVS200X0Y0Z1030 is NOT a version number), etc. On other side Debian... is STILL just WORKS. As it did all along 7 last years.
Hardly can disagree on any point made. Thou quoted above is necessarily true. I would say nothing about U.S. - but I can comment about Germany where I live.
After countries of estern block have joined EU, something similar started happening over here. And even more radical: there is no such wide cultural gap between e.g. Germany and Poland as there is between U.S. and India. Business started dumbly moving work from West to East. In Germany on average employee costs about 3-5k Euros. In Poland you can get "best of bread" for about 2k, while prices for middle/low level specialists can be as low as 500 euros/month.
When you look at how the money - 5000 in Germany, 2000 in Poland - gets distributed, you start understanding the real difference. From 5k euros, about 2k consumed by social system, another 1k consumed by all kinds of mandatory insurances. Substract cost of living and you get 750 - all I get on my hands. Ironically, specialist from Poland would get the same cash in the end. It's just Poland doesn't have pile of mandatory insurances, it doesn't have fat ugly over-abused social system, it doesn't have such high taxes required to run such complicated and expensive tax system.
In the end, it comes down to populistic measures (like improved safety in social sector) used by politicians to boost ratings which in the end hits back in shape of new taxes at people who voiced and voted for it.
[Offtopic];-) I haven't noticed your nick.[/Offtopic]
To the practicalities. Use case. My company. We switched recently to SVN. Pilot of SVN was - any guesses? - documentation repository, filled with WinWord and OOo documents. We have adopted OOo for internal documentation about 3 years ago - some time after 1.0 release. (M$O files when open from networked drives gets corrupted often - sad reality).
SVN + OOo are good friends.
SVN supports well binary files. That's for first. (As opposed to patch centric decentralized systems: you can't diff binary files).
Second. SVN has nice feature: "require-lock". Once that flag is set on file, the file would be checked-out as "read-only". OOo notices that and opens file read only. (One can only dream about such function in M$O: opening files in read only/viewing mode.)
If one wants to modify file, he has to acquire lock. That prevents two people working on the same document simultaneously and also protects file against possible accidental changes. Overall, we yet to run into any serios problem with the combo.
The major downside is mentioned elsewhere: you can't diff (and OOo support for changes is at best buggy). On other side, since that's commercial company (we do not have redundancy of distributed development model): only one person is charged with working on particular document at any given time. And changes must be filed separately in the (now in SVN) revision log.
P.S. The unavailability of diff, can be somewhat offset by internal OOo's versioning. Thou normally you can't expect to have OOo's version for every SVN's revision.
What are you smoking? If you went off to sightseeing - trees, rivers, nature, etc - iow no internet. Or your favorite Cisco router died during OS upgrade. Where are you going to commit to????? By "disconnected operation" I meant precisely that - "disconnected operation". With SVN you are out. With Arch I can still work localy and commit localy - having all my changes the way I like them. That's for first.
Second. You did N changes in my-experimental-branch. Time have come to bring the changes onto the trunk. What happens with SVN? All N changes will be lumped together in huge blob called "merge". With decentralized systems, trunk will receive from my-experimental-branch N patches + possibly one more additional patch to resolve conflicts. All changes are there - with all info attached. With SVN that info is not there: only way to see it - is to guess where from the original changes have come. Few month down the road it might be not that easy to guess which of the my-experimental-branch-001234/005678 was the source of the merge. The difference is that branches in SVN are completely independent from each other. In systems like Arch branches are nothing more than set of patches: they can be combined - the point of forking can be easily found by looking at the list of patches in the branches.
Third. Not every SVN repository allows everybody to create tags/branches. What's quite good practice - tagging and branching in centralized systems better to be done by dedicated repository admins. We have in office about 2.5k branches - and I know the pain of managing that mess.
To conclude: you need to try decentralized system - e.g. GNU Arch or Darcs - once. (Darcs is quite straightforward and easy to start with, compared to both GNU Arch and BitKeeper.) I also have had problems getting all the differences between classical CVS-like systems and newer Arch-like systems. And read SVN book once more - it's good - just to understand what/why SVN can and cannot.
P.S. http://wiki.gnuarch.org/SubVersionAndCvsCompariso
I have read once BlackDown.org's license. The license is flat out prohibit redistribution. End of Story.
From the mail lists, my impression (developers refused to discuss directly the contract with Sun under which they do port Java to Linux - they seem to be under NDA) was that most of the restrictions came from Sun, not from BlackDown people. Debian cannot give you BlackDown's port of Java, you have to go to BlackDown.org to get it: that's part of license.
And now it seems that Sun's JRE/JDK license has the same problem: it prohibit redistribution. Or as I have understood from the discussion, it attach conditions to redictribution, making Debian (and consequently SPI) legally liable for potential damages. Getting Sun's JDK from Debian and getting Sun's JDK from Sun are two _legally_ different things. As long as restrictions there, no way (even in non-free) such package can appear. Sun's people reacted and said they will fix the problem with license. We just need to wait couple of weeks to see what will come out of that.
P.S. Try to imaging your position as Debian Project Leader (DPL). You have responsibilities. In fact you are responsible for all decisions made during the time you are in power. Someone (behind your back) includes package with long list of restriction into the Debian. And then company whose work got included sues SPI for damages from illegal distribution of the software package. SPI would of course blame responsible - not the guy uploaded the package - but project leader, DPL. The Debian policies exist to avoid such situations - to avoid needless legal risks. You just can't ignore them, because you potentially jeopardize others.
Since when beta became "shipped product"? M$O 2007 by its name tells that it's not out until next year. End of story.
The U.S. has the "best democracy money can buy" (c) whoever said it first.
I think, somebody there over the pond, has to start a case against gov't: the executive branch become so obese, that only voice of big wallets can really reach it. That's discrimination against normal people who cannot represent their interests (iow cannot buy good lobby) as good as big business can.
As it looks from Europe, you have basicly three lobbying groups for every branch of law: big business lobby, medium/small business lobby and independent lobbists. Big business buys another law by making a pact with medium/small business lobbies. Independent lobbist are of course left off board. I cannot stop myself thinking that this is conduct anti-trust law designed to deal with.
You got it wrong. Or got only half of it. Sharing is a double edged knife: it can hurt as much as it helps.
To explain it simply, decentralized systems allows me to have local intermidiate version of file. In centralized system, if I want my changes be protected or simply numbered (so I can rollback later), I have to commit working files into repository.
If my changes are at very very early stage and not yet ready for general use, commiting would force others to do additional steps to avoid using my new (raw, broken) version of file. If there are many commiters like that - and that's pretty normal with huge source code repositories - the life can easily become nightmare. (*)
Decentralized version control allows you to have local repository. And consequently, it allows you to commit you changes to your repository. It doesn't forces my changes on everyone before proper time X, but allows involved people to pull changes directly from my local repository and for example to test their own changes along with my ones.
When time comes, I can submit all changes from my local repository to global public one.
P.S. Another good use for decentralized version control, is disconnected work. If you are with your notebook in office - you can commit. At home - with centralized repository in office - you can't. With decentralized system - you can commit directly on your notebook, and later on when reaching office, commit changes from notebook made over week-end.
(*) That's the reason why in centralized systems, changes are very big - people tend to commit less to avoid needless breakage. In decentralized systems changes are often small and abundant. You can afford the luxury.
OpenDocument is XML + Styles + etc stored in single ZIP file.
If one can teach OOo to work with unzipped directory as if it was OpenDocument file, then answer to your question would be "yes".
At moment the answer is "no".
P.S. Thou, OOo can preserve multiple versions of a document inside of document itself. "File" -> "Versions...". I'm slowly teaching our documenters to use that thing and preserve all public releases of documents with OOo versions. Not as good as diff+svn, but still something very useful you can't do with M$O.
P.P.S. Mac OS X has funny concept of "bundles". Bundle is basicly directory with some application assigned to open it. As user concerned, it behaves just like file. For example all applications in Mac OS X are bundles (and e.g. application icon is just file in prescribed location in the bundle). Since Windows/GNOME/KDE do not support such stuff, the chances of the support in OOo are very slim. W/o proper support in OS, handling of such bundles for average user can be very burdensome. As another good and closer to on-topic example, MacOSX uses bundles to save RTF files with embedded pictures: inside of bundle one would find rtf itself and all images rtf references.
Would be bundles supported in all OSs then zipping would be needed only to send files across net.
What you smoking? M$ never shipped PDF support with any of its applicaitons.
Adobe Acrobat Reader (and in some case FoxIt Reader) is the standard item on all installation lists - lists of non-M$ software required to make M$ Wind0ze any usable. It's just like WinAmp or iTunes for MP3s.
PDF is standard. Period. Do we like it or not, more or less all industries I have worked with preinstall Acrobat Reader on all computers. It's less relevant on home desktops - but as soon as you get any documentation for a device you run into the PDFs.
M$ will have to challenge what people like most in PDF: stability. No, it's not quality of print nor performance - it's stability. Do I like Acrobat Reader or not, I still can open any PDF created many years ago w/o any problem. As time had showen, M$ has problems with long-term commitments. If they will manage to keep Metro afloat for 8-10 years - the time it took PDF become standard - then it might become new standard. Not sooner.
P.S. [Sarcasm] The only way for M$ to make file format which will last that long, is to make it very very very bad. So that to fix all the problems of the version 1.0 and to release version 2.0 they would need a decade. Just like it happened with WinNT to Win2k transition (that took 8 years, NT4 delays included). Thou I can hardly imaging something worse than WinNT 4.0. But M$ is definitely capable of surprising us. [/Sarcasm]
Security clearance is nothing new. Nor it is indicative. Case: DVD/CSS v. DVD John. CSS was secret just because is was easy to crack.
On-topic. Sounds as good idea. Let's just hope that secretive implementation wouldn't hold the evolution of the system. Good sign would be a competition - both hardware competition (devices from multiple manufacturers) and content competition (programming from different providers). If they will try to hold everything to single company - then I think two years later the service would suck. As it always does when there is no competition.
P.S. One of embedded Linux system I developed was booting from flash in under 10 seconds. With 7-8 seconds out of 10 eaten by Phoenix BIOS.
In most other languages, I have a choice how to link to ActiveX. And I can avoid it altogether.
For example, some applications I have ported from VB have to use ActiveX for some functionality (wierd serial protocol used in target application field). In C/C++ people (can and do) load the library and request needed interfaces. Can you do that in VB? - No. But that's precisely what was done in C++. There are several versions of the aforementioned library in use. We tested with only one version. With VB we have to install and register it as ActiveX. With C++ we just used it as normal DLL - loaded, requested functions, got interfaces and do job. In VB you can't operate interfaces directly - you are not supposed to.
But in the end you are right. Biggest problem of my ex-employer was deployment. In fact people did tests that instalation of our software package wouldn't break VB installations for that purpose. We had bought VB6 in part for that purpose - thou it didn't worked out in the end. (M$ promised backward compatibility - and my employer falled for it - but none of the VB4 applications were ever successfully ported to VB6. In fact nobody expected that porting would be needed, since M$ claimed "backward compatibility". Always sounds good.) And still at least once per month we were getting complain about something ending up broken. Until I rewrote all the applications in C++.
Hats off. Pioneer of microcomputers is passing away.
First. Perl allows you to build version checks in to the scripts. It's just nobody bothers. Also quite normal practice for Perl to ship all required modules with perl application and leave them in application subdirectory. Then at run-time you can check if system version is Okay and use it. If system version isn't okay - or module isn't installed at all - application defaults to use it's own internal version. (*)
Second. ActiveX components are global and referenced by GUID. You can have two/more different versions of the same library in the system. But only can be registered at a time - only one would be used by *all* applications. Your system has library A of version 1.0. You install new application and it installs the library version 1.1 and register it. Any application dependant on behaviour of library version 1.0 would break. Worse case, is that many libraries miss versioning info at all - even Microsoft own ones.
Third. Easy start. Cheap programmers made many people happy. On one side. On another side there are people like I am. It's not that I - as system programmer - feel any competition of VB users. It's just they often make promises they can't deliver on (with software it's easy to underestimate complexity). Then customers have to run to some hardcore programmers like I am and beg to fix the system overnight since deadline was yesterday. It's not very pleasant situation I was finding myself several times.
I think for easy application development people has to use specialized systems. Consider M$ Access for data bases. Consider LabView for scientific applications. Consider Perl for text processing. Consider PHP for web applications. Consider Python for portable simple GUI applications. Almost every application field has "standard" tool which allows specialist in the field to easily develop and deploy application. VB's problem is that it tries to be too universal. Bit like Java: good for everything in general, but isn't best for anything in particular.
(*) While proof-reading the paragraph, I have noticed that's the same approach Apple used with its "frameworks". The guys are not shy and freely borrow ideas from Unix. I wish M$ did something like that to end the "DLL-Hell." But seems stuff like Aero is the current priority.