This is not true, I run Flash Media Server on Linux at home for development purposes. It's supported out of the box that way, though the scripts are RedHat specific (though it took me all of 5 minutes to fix that).
You don't really need FMS for this though; users are not likely to be jumping around in the video or needing variable bit rates changed up on the fly. A simple Apache install will do fine.
Definitely recommend Flash for the front end, a museum isn't going to want user controls which look like typical computer controls; particularly an art museum.
iPhone gets all the hype, and indeed it's doing quite well for itself, but it's only selling 2/3 as many units as RIM (though catching up), and it lags far behind Symbian which single handedly enjoys > 50% share.
You may find that with such a blemish, any AppleCare warranty support is now void.
My brother's MBP had a video card with a known issue where some times the video card would not output any video (either to the LCD or to the display port). He had the exact model number which experiences this problem, and supposedly every MBP with that model video card is affected and eligible for free repair even out of warranty.
He took them up on it (he was still under AppleCare, having bought the extended version), but because there was a dent in his case, they claimed the video card was damaged by the dent, and they further claimed they would not be able to repair the damage without replacing the entire chassis. I had seen the dent, it was very small; more of a scratch and a dimple - there's no way this was responsible.
What should have been a free repair cost him $800.
Yeah, and these are part of a conversation about using encryption in your email.
I'm not sure I understand the objective of your original point (that being that there is no intrinsic requirement that email be accessed with a password).
Maybe there exists some corner case out there where passwords (or some other secret) aren't used to control access to email, but the overwhelming majority of email use requires it.
Now, were you to send encrypted e-mail, the story would be very different
That's what this topic is about, were you having a different conversation? Maybe I misunderstood your earlier post, but it read to me (and still does upon re-reading) that you're taking the stance that because email is not necessarily encrypted (there exist unencrypted emails, even if it's most of them out there), therefore email is not eligible for DMCA-style protections.
The fact that most people use email in an unencrypted manner is irrelevant to the discussion. DMCA protections do not require that there exists no non-encrypted version of a medium, it merely requires that you employ encryption in the instance at question.
Email encryption neither requires nor is particularly aided by ISP level encryption services. Encryption would be end point encryption; user to user using PGP, GPG, or similar. All your ISP communications channels could be straight unmodified data (the data they receive from the sender is the data that exists on the disk, and it is the same data that is transmitted to the recipient), and even they could be free from authentication. This doesn't change whether you can encrypt over this medium, and you can still be certain that only the intended recipient is able to read a given message outside of a compromised private key.
The same way it works for the phone and postal systems. This judge's ruling differs greatly from existing long-standing precedents on what are and are not private communications.
Right, like posting on a Blog is public and sending an email (which requires a password "envelope") is private.
Sending an e-mail doesn't require a password at all. Neither does receiving an e-mail.... Now, many providers of e-mail services only permit you to access your mail by authenticating with them using a username and password
Creating a video doesn't require DRM at all. Neither does viewing a video... Now, many providers of video services only permit you to access a video by wrapping them in DRM.
DMCA doesn't require that there are no non-protected channels, it only requires that the channel in question is protected.
Free speech requirements only applies to the government.
It is in turn a form of free speech for a non-government agency to refuse to give voice to someone else's exercising of their own free speech. So a news agency which refuses to repeat points of view it finds objectionable is itself a form of free speech.
Like it or not, news agencies must filter whose points of view they're willing to give voice to. Even in a perfect world, with a perfect news agency, there is no meaningful way to give equal weight to every point of view out there. Part of a news agency's job is to make a determination as to which voices are worth repeating and amplifying, and to what extent. This is a big part of why Freedom of the Press is so important since it is an extension of freedom of speech. They are even covered by the same amendment. A government which controls the press controls speech.
"Balanced news reporting" is actually, "giving weight to the opinion of others in direct proportion to how much merit we think that voice has based on our personal views and our understanding of those of our subscribers."
Unbalanced reporting this may be (I'm not certain I would agree), but a freedom of speech issue it most certainly is not.
I work at a company which deals with live infectious diseases every day. In order to even enter certain buildings on campus, you have to have the appropriate immunizations for the diseases being researched in that building. Our badges have colored stripes on the back indicating what vaccinations you've received (the vaccine name is also written inside the colored stripe, for colorblind individuals).
If you're tech support or facilities, you basically need every common vaccination that's out there because you may be called to enter any building on campus. If you're a researcher, you definitely need the vaccinations for the buildings you work in, but most are asked to get the full gamut.
If you're in a situation where you're exposed to infectious disease as part of your job, I see no problem with requiring you to be protected from that disease. Standard workplace safety has people using safety equipment every day; this is not different except that failure to comply can unknowingly cause an epidemic and kill tens, hundreds, maybe thousands of people.
You'll find in the followup conversation that I describe why losing complete revision history is a big deal. Specifically WRT being able to prove ownership of code in the event of code theft.
No, I wouldn't trust such a promise (even in the form of a contract) to ever work out in my favor. What would happen is Disney would decide they're done with this business and are exiting it. So they spin off that part of the business as its own legal entity (or sell it to someone), which after a year or so declares chapter 13.
Consumers would be left with no recourse; Disney can no longer be held responsible, they don't own that contract that this spun off company is now in fault of. That company is under bankruptcy protection without anywhere near enough assets to meet its obligations. Consumers get nothing.
It's too easy for corporations to shuck obligations when they're exiting a market. Any consumer protections surrounding such an event built into contracts are a lie and unenforceable.
The difference being that any wall will be a screen for a projector, while you may have a hard time finding a working TV from this era to hook up to that old DVD player. Modern electronics also have a much shorter life than old mechanical projectors. As they get more complex, they become more vulnerable to component corrosion, defects introduced by storage conditions such as heat/cold, and simple use wear such as motors which eventually burn out or capacitors which eventually leak.
20 years from now, there'll be far less 20-year-old-but-still-functioning technology as there is today. Invest in progressive protection; rip your DVD's to video files (Handbrake + MetaX), and as formats shift over time, convert them as needed.
I'll agree, although I don't have much experience with svn+ssh; it is easy to misconfigure it in a way that would allow data forging (or perhaps more aptly put, it's hard to configure it in a way that doesn't). This is in part why we went with mod_dav_svn as our SVN protocol. This does have the concern you voiced earlier about storing passwords in plain text on the client machine.
I haven't done it, but it's supposedly possible to configure DAV SVN to utilize client certificates for authentication (TLS auth among others). Your communications would be encrypted, and only people who have access to a user's personal certificate would be able to pretend to be that user. It's discussed at http://svnbook.red-bean.com/en/1.4/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authn.sslcerts . Then your SVN server has a CA it trusts, as do your SVN clients. The client cert can even itself be password protected if you want so that even if the client cert gets intercepted it still can't be used without a password (this of course defeats saving your password so you don't have to retype it each time you do a svn operation).
This is about the highest order security and authentication available; it's all OpenSSL stuff. So it all depends on what level of security is appropriate.
I get your point about not being able to trust the repository if developers have unlimited access to it. That's not the case for us; only I and one other person have that kind of access to the repository, but he or I could do it. GPG signing tags is an interesting idea. What is the unique data that is signed (to protect against a replay)? I may borrow that idea and have our build system GPG sign an MD5 manifest when it creates the release tag. Even if someone had svnadmin access to be able to forge entries in the repository; they wouldn't have the build system's GPG key.
Authenticity of the code isn't as important to us as being able to prove ownership of the code, so although I respect that what you're describing is valuable to some people, I'm not sure how much benefit it brings us (but like I said, if I can cryptographically sign a hash manifest, might as well).
FWIW, thanks for the conversation, this has been enjoyable.
I don't want to speak as an authority because it's been a long time since I did svn+ssh setup; but I don't believe there is svnserve involved in svn+ssh:// like there is in svn://. It's my understanding that you could use a box which has no svn software installed on it as long as it has a correctly formatted repository and an ssh server. User access is controlled not through svn's built-in authz file, but via filesystem permissions and user accounts on that machine.
I might be wrong; as I mentioned, it's been a while - we use mod_dav_svn on Apache - but what you're describing differs from how I remember it.
Anyway, it's a bit of a tangent.
The legal consequences come in the form of corporate espionage. It's a very real problem that is rarely talked about at large. We talk about it a lot where I am because we have experienced it first hand. Although it's true that there's value in being able to prove when and why a change was made, and by whom; this wasn't what I was speaking about (and you're right, svnadmin commands mean that if you have administrative access to the repository, you can make it look like whatever you like).
Instead I meant to talk about being able to prove that my company developed a technology, and not a competitor who shows up on the scene with an identical offering (same code and everything). If we can produce revision history including bug fixes, feature additions, etc, while our competitor can only produce a single build and possibly changes after the date they illicitly acquired the code base, then we have the legal recourse necessary to shut that down.
If they steal a laptop with a SVN working copy on it, they get that version of the code but nothing else. If they steal a laptop with a git repository on it, they have all the same ability to produce complete revision history as we do. They also potentially get access to in-progress projects that the owner of the stolen laptop wasn't even working on.
Laptops can be legitimately stolen (guy's bag gets switched at a coffee shop he frequents every morning), or they could be stolen through espionage (we'll give you $30,000 if you "lose" your laptop in our favor).
With SVN we have the access logs on our server that shows who checked out what working copy and when. If someone wants to steal complete revision history and they're not an SVN admin, they're going to leave fingerprints all over that operation (one project is about 12,000 files and about 15,000 revisions; getting complete revision history for this is going to leave a very easy to find access pattern).
Don't get me wrong; git is fantastic, and certainly has many useful functions. The fact that you have a local copy of the complete repository (aside from disk space) is fantastic for offline work. The fact that it's distributed means that you don't have a single point of failure source control server, etc. There are just a handful of design decisions which make it a non-option for us.
Also, regarding authenticity of release tags; I'm not sure I get this point. We generate a tag (eg/tags/release_4.1.7e) at revision 15489; that then is the build number of the release. Unless you're an svnadmin, there's no way you could ever forge this; even if you deleted and recreated/tags/release_4.1.7e pointing at a different version of the code, the build number would still be wrong (as would the date), and the svn log would show who was trying to falsify a build. In addition for us, a specific service account creates the build and the release tag; so it would also have the wrong user ID. Users don't have access to tag in this space (in fact, we use tags for more than just releases, so we break from convention by making/tags/releases/2009/release_4.1.7e - with nearly weekly minor releases and monthly feature releases, this just makes it a bit easier to drill in), so again unless you're an svnadmin, you don't even have the capacity to try to forge a release no matter how obvious it would have been.
It's certainly true that the branching tools we wrote aren't specific to any given source control system; the git-vs-svn opening of my response was mostly just to point out that there's a better way to use SVN.
You might be right about svn+ssh being poorly documented; I never had a hard time getting it up and running, but most of the concepts were pretty familiar before I started, so I might not be the most representative. As to it being poorly supported, I'd be surprised; it's essentially filesystem access over an SSH tunnel. Local filesystem access is what you use when you want to debug things to know if it's a problem with your transport protocol or a problem with your repository. You don't have to use authz access, you can rely on disk permissions, and especially if you have root access this is extremely easy to debug any issues with.
You can do diffs while offline with SVN as well; inside the.svn folder is a text-base folder within which is an original copy of each file. You can't access revision logs, but you can compare local changes.
I know where I work, I can't go into a lot of details, but I can say that it would be unwise of us to use a source control system where each laptop contained revision history on it. There are certain things from a legal or a patent perspective which we need to be able to prove we're the original creators of. Source history is a good way to demonstrate this. If a competitor got access to a complete revision history, it could be a very expensive compromise. This is a major weakness for us for git or other distributed source control models, no matter the benefit such a system brings.
svn+ssh doesn't store anything in clear text. If that's a security concern for you, there's already a solution in place. Git is not the be-all and end-all solution to source control; it does many things very well, but there are a few things it does very poorly (repository control; with git, developers have a local copy of the repository which means that a stolen laptop comes with complete revision history). When the systems you're working on have certain sensitivities (legal, patent, security, etc), this can be a major weakness.
We do something very similar to the original submitter at work. We have 10-15 project branches open at a time. For us, we make sure that our code is subdirectory-agnostic (meaning it can run on the root of the website, or it can run out of a subdirectory). We use directory paths for branches, and we use internal DNS records for environments. http://de-appname/branchname would be a development branch while http://va-appname/branchname would be a validation branch.
For our lifecycle, we have development, validation, staging, pre production, and production. Development and validation are the only branching locations; staging, pre, and production are each single-path locations (though staging is a branch reserved for this purpose, pre production and production are/trunk)
On http://de-appname/ and http://va-appname/ there is essentially a directory listing along with the fully qualified branch name, revision, most recent contributor's name (even spelled out by looking up their record in LDAP), commit time, and most recent log message. Developers get a drop-down menu next to project branches which they can use to update the working copy there on that shared server (does a little ajax call and shows you the result in real time as though you were at a terminal). You can also create clean checkouts and even create new branches (either off of trunk or off of another branch). Finally you can even close a branch through this interface; it deletes the branch with a meaningful log message, and cleans up the files on that server. All through a web interface, no need to remotely log into a machine for this purpose. There's no reason for someone to administer this, each developer creates a working copy when and where he thinks it makes sense for himself.
Because our back end is SAP, we don't have to deal with multiple database environments. There's no "create a new copy of SAP" - indeed when this is something that's organizationally important (testing a major upgrade), it's a multiple day long process. We have a fixed set of data environments, and these are tied to hostname (going back to de-appname, va-appname, stage-appname, etc). If there were multiple database environments to worry about (eg, you wanted to be able to effectively branch database environments too), it wouldn't be a huge deal to set up a template database and have the same scripts we use to manage branches through a web API clone that database and update config in the appropriate app.
The key that I'm trying to get at is that you should create a web based tool to allow developers to manage this themselves. The developers will thank you because they'll be able to get what they want faster than you could have provided it, and they'll have control over when where and why working copies of their work in progress appear.
It would lower the barrier to espionage. You wouldn't have to beat your competitor to the market with their invention - which although this does happen, it's hard because you still have to get it to a patentable state without the benefit of having the minds in your employ which are producing the invention. So under the best circumstances you are still under a tight timeline (unless your competitor is delaying patenting, as happens for example in the pharmaceutical industry where the time between patenting a product and being able to sell that product is consumed by years of preclinical and clinical trials and regulatory approval periods).
Simultaneous invention clauses would let your competitor then even wait a month or two after you patent it to identify issues with your implementation that only appear when you start to put the product to real world use. Then they file their patent, and potentially lock you out of fixes to your own product when they make the case that invention of the fixes could not have been simultaneous because you only produced them in response to real world use, while their version had it all along (as their extensive though forged documentation proves).
How much time is too much time for independent invention to no longer matter? 1 year, 5 years? Anywhere within my patent life span someone could show up claiming independent invention and undo my patent. Two non-colluding inventors owning the same patent would effectively mean there was no patent.
I could go on. Letting two inventors own the same space has a lot of issues beyond just defeating the fundamental principles of patents. The point is a guaranteed limited monopoly in return for sharing the details of the technology with the world. Two competitors in the same space is not this.
Of course, proving independent invention is next to impossible
I'm guessing this is a big part of why they don't honor independent simultaneous invention. It means that if you had a mole in a competitor's development space, they could secretly feed you enough data that you can reproduce the invention cycle on your own with only a slight delay.
Disregarding the inability to authenticate independent invention; if two inventors did have a patent on the same invention, then licensing becomes a bidding war for which inventor will offer a lower licensing cost. One of the main purposes of a patent is to allow an inventor to recover the cost of research & development; now these inventors would instead be in a position where they were trying to minimize loss.
They are in the business of selling a service meant to counteract software piracy. Any numbers they quote on the prevalence of same should be distrusted since they have a conflict of interest in reporting this accurately.
Even with all best intentions, they are likely to make educated guesses in their own favor rather than with a balanced perspective... and since their numbers aren't based on an actual desktop population sample, but extrapolated from other sources, then the possible accuracy is automatically highly suspect.
You're wandering out of my area of expertise, but the way I understand it, if it's a corporate deployment, it's possible to have an internal corporate app store, and I think it's even possible to push apps to phones (so they'll have an icon on their springboard for the training without having to go explicitly install it).
If you're talking about a public deployment, then you could push your app through the App Store like any other.
With Flash, you should be able to have it load training materials from an Internet server so that users don't have to download a new version each time training materials are updated, but I doubt you'll be able to play SWFs (for the same reasons Apple won't let Adobe put Flash on the iPhone); you'd have to have your app load an XML file with all the display instructions embedded and take care of rendering the display instructions yourself.
We built that sort of training app a few years back. The customer wanted to be able to have a single set of SWFs they could reuse by modifying the data. Made a nice little web interface to create new training program slides and quizzes; it spit out XML files and stored them on the server, then when you fired up the training app, it gave you a drop-down of all the training files it found on the server.
Yeah, there's no PM system here. I'm sorry to say I don't have any dead tree books to offer advice on. I learned ActionScript in the 1.0 days and have advanced my knowledge each time the language advances mostly through either in-program Help files or online documentation.
Today I'm working on connections to and passing data around in Flash Media Server. I'm working my way through examples in the documentation that comes with Flash Media Server, and Googling for more details on specific methods and their arguments (I don't just copy the examples verbatim, I try to fit the examples into the actual code base I'm working with).
Javascript is an OK language, but it doesn't really have anything ActionScript doesn't have. They're both based on ECMA Script, so the syntax is similar. They both have event systems.
ActionScript has strong typing as an option (though you can elect to go with weak typing if you wish), implicit getters and setters for properties (eg, function get foo():String { return this._foo; } function set foo(newFoo:String):void { if (newFoo != 'bar') this._foo = newFoo; }) which allow you to start adding data validation or trigger other behavior when you change a property. It's got method and property visibility controls. Class level constants, static properties and methods, interfaces, and a whole slew of other high-order OOP functionality that JavaScript is just missing.
I do quite a lot of work in both languages. Maybe it's a style choice, but I'm definitely a much bigger fan of ActionScript than JavaScript. Fortunately their domains do not overlap very much (and in fact I do quite a lot where the two talk with each other).
On a side note, not sure why my parent post got marked as Troll; I'm guessing someone has a beef with the politically based comments I posted yesterday in a different thread, and is trying to punish me here.
It's not a "last ditch effort" to remain relevant. It's just Adobe continuing the tradition of ubiquity of their platform. Apple won't let them put a runtime on the phone, so they'll deploy native code instead.
Apple supports the use of Web technologies like AJAX to build applications based on the iPhone's Safari browser.
Sorry, but there's a big difference between an AJAX app and a native app. Try writing a browser based graphical game on the iPhone; it's going to fall on its face pretty quickly.
for BlackBerry handsets, thanks to a new SDK from Research in Motion.
Hmm, convince developers to learn a whole new SDK for a single platform, when they can stick with a mature language and toolset they already know, deploy it in the browser, on the desktop (via Air), and on basically every phone on the planet that can run custom apps, including the BlackBerry?
Sorry, this whole article is bunk. Adobe isn't struggling with relevance, they're just making sure it doesn't start to slip, as Apple is so strongly trying to make it. In fact, this probably backfired on Apple a bit - Flash apps running as a native binary will probably have access to device functions which the normal Flash runtime wouldn't have.
Adobe needs now is to convince developers that Flash is better than the other options — and that could be a tough sell
I'm guessing this sale has already been made. A lot of developers like working in Flash. Actionscript is a surprisingly elegant language. Based on the number of Flash apps which already turn up all over the web, a whole new segment of developers are seeing this as access to a development platform which was previously closed to them.
Slashdot Mirror
This is not true, I run Flash Media Server on Linux at home for development purposes. It's supported out of the box that way, though the scripts are RedHat specific (though it took me all of 5 minutes to fix that).
You don't really need FMS for this though; users are not likely to be jumping around in the video or needing variable bit rates changed up on the fly. A simple Apache install will do fine.
Definitely recommend Flash for the front end, a museum isn't going to want user controls which look like typical computer controls; particularly an art museum.
Actually the iPhone is only 13.7% of smart phone sales as of Q2 2009.
iPhone gets all the hype, and indeed it's doing quite well for itself, but it's only selling 2/3 as many units as RIM (though catching up), and it lags far behind Symbian which single handedly enjoys > 50% share.
You may find that with such a blemish, any AppleCare warranty support is now void.
My brother's MBP had a video card with a known issue where some times the video card would not output any video (either to the LCD or to the display port). He had the exact model number which experiences this problem, and supposedly every MBP with that model video card is affected and eligible for free repair even out of warranty.
He took them up on it (he was still under AppleCare, having bought the extended version), but because there was a dent in his case, they claimed the video card was damaged by the dent, and they further claimed they would not be able to repair the damage without replacing the entire chassis. I had seen the dent, it was very small; more of a scratch and a dimple - there's no way this was responsible.
What should have been a free repair cost him $800.
Yeah, and these are part of a conversation about using encryption in your email.
I'm not sure I understand the objective of your original point (that being that there is no intrinsic requirement that email be accessed with a password).
Maybe there exists some corner case out there where passwords (or some other secret) aren't used to control access to email, but the overwhelming majority of email use requires it.
Maybe you haven't seen this: http://www.adobe.com/devnet/swf/
This is 278 pages of very straightforward and in-depth documentation on the SWF file format.
That's what this topic is about, were you having a different conversation? Maybe I misunderstood your earlier post, but it read to me (and still does upon re-reading) that you're taking the stance that because email is not necessarily encrypted (there exist unencrypted emails, even if it's most of them out there), therefore email is not eligible for DMCA-style protections.
The fact that most people use email in an unencrypted manner is irrelevant to the discussion. DMCA protections do not require that there exists no non-encrypted version of a medium, it merely requires that you employ encryption in the instance at question.
Email encryption neither requires nor is particularly aided by ISP level encryption services. Encryption would be end point encryption; user to user using PGP, GPG, or similar. All your ISP communications channels could be straight unmodified data (the data they receive from the sender is the data that exists on the disk, and it is the same data that is transmitted to the recipient), and even they could be free from authentication. This doesn't change whether you can encrypt over this medium, and you can still be certain that only the intended recipient is able to read a given message outside of a compromised private key.
The same way it works for the phone and postal systems. This judge's ruling differs greatly from existing long-standing precedents on what are and are not private communications.
Creating a video doesn't require DRM at all. Neither does viewing a video... Now, many providers of video services only permit you to access a video by wrapping them in DRM.
DMCA doesn't require that there are no non-protected channels, it only requires that the channel in question is protected.
You're right, my apologies. I misunderstood the behavior which was being criticized.
Free speech requirements only applies to the government.
It is in turn a form of free speech for a non-government agency to refuse to give voice to someone else's exercising of their own free speech. So a news agency which refuses to repeat points of view it finds objectionable is itself a form of free speech.
Like it or not, news agencies must filter whose points of view they're willing to give voice to. Even in a perfect world, with a perfect news agency, there is no meaningful way to give equal weight to every point of view out there. Part of a news agency's job is to make a determination as to which voices are worth repeating and amplifying, and to what extent. This is a big part of why Freedom of the Press is so important since it is an extension of freedom of speech. They are even covered by the same amendment. A government which controls the press controls speech.
"Balanced news reporting" is actually, "giving weight to the opinion of others in direct proportion to how much merit we think that voice has based on our personal views and our understanding of those of our subscribers."
Unbalanced reporting this may be (I'm not certain I would agree), but a freedom of speech issue it most certainly is not.
I work at a company which deals with live infectious diseases every day. In order to even enter certain buildings on campus, you have to have the appropriate immunizations for the diseases being researched in that building. Our badges have colored stripes on the back indicating what vaccinations you've received (the vaccine name is also written inside the colored stripe, for colorblind individuals).
If you're tech support or facilities, you basically need every common vaccination that's out there because you may be called to enter any building on campus. If you're a researcher, you definitely need the vaccinations for the buildings you work in, but most are asked to get the full gamut.
If you're in a situation where you're exposed to infectious disease as part of your job, I see no problem with requiring you to be protected from that disease. Standard workplace safety has people using safety equipment every day; this is not different except that failure to comply can unknowingly cause an epidemic and kill tens, hundreds, maybe thousands of people.
You'll find in the followup conversation that I describe why losing complete revision history is a big deal. Specifically WRT being able to prove ownership of code in the event of code theft.
No, I wouldn't trust such a promise (even in the form of a contract) to ever work out in my favor. What would happen is Disney would decide they're done with this business and are exiting it. So they spin off that part of the business as its own legal entity (or sell it to someone), which after a year or so declares chapter 13.
Consumers would be left with no recourse; Disney can no longer be held responsible, they don't own that contract that this spun off company is now in fault of. That company is under bankruptcy protection without anywhere near enough assets to meet its obligations. Consumers get nothing.
It's too easy for corporations to shuck obligations when they're exiting a market. Any consumer protections surrounding such an event built into contracts are a lie and unenforceable.
The difference being that any wall will be a screen for a projector, while you may have a hard time finding a working TV from this era to hook up to that old DVD player. Modern electronics also have a much shorter life than old mechanical projectors. As they get more complex, they become more vulnerable to component corrosion, defects introduced by storage conditions such as heat/cold, and simple use wear such as motors which eventually burn out or capacitors which eventually leak.
20 years from now, there'll be far less 20-year-old-but-still-functioning technology as there is today. Invest in progressive protection; rip your DVD's to video files (Handbrake + MetaX), and as formats shift over time, convert them as needed.
I'll agree, although I don't have much experience with svn+ssh; it is easy to misconfigure it in a way that would allow data forging (or perhaps more aptly put, it's hard to configure it in a way that doesn't). This is in part why we went with mod_dav_svn as our SVN protocol. This does have the concern you voiced earlier about storing passwords in plain text on the client machine.
I haven't done it, but it's supposedly possible to configure DAV SVN to utilize client certificates for authentication (TLS auth among others). Your communications would be encrypted, and only people who have access to a user's personal certificate would be able to pretend to be that user. It's discussed at http://svnbook.red-bean.com/en/1.4/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authn.sslcerts . Then your SVN server has a CA it trusts, as do your SVN clients. The client cert can even itself be password protected if you want so that even if the client cert gets intercepted it still can't be used without a password (this of course defeats saving your password so you don't have to retype it each time you do a svn operation).
This is about the highest order security and authentication available; it's all OpenSSL stuff. So it all depends on what level of security is appropriate.
I get your point about not being able to trust the repository if developers have unlimited access to it. That's not the case for us; only I and one other person have that kind of access to the repository, but he or I could do it. GPG signing tags is an interesting idea. What is the unique data that is signed (to protect against a replay)? I may borrow that idea and have our build system GPG sign an MD5 manifest when it creates the release tag. Even if someone had svnadmin access to be able to forge entries in the repository; they wouldn't have the build system's GPG key.
Authenticity of the code isn't as important to us as being able to prove ownership of the code, so although I respect that what you're describing is valuable to some people, I'm not sure how much benefit it brings us (but like I said, if I can cryptographically sign a hash manifest, might as well).
FWIW, thanks for the conversation, this has been enjoyable.
I don't want to speak as an authority because it's been a long time since I did svn+ssh setup; but I don't believe there is svnserve involved in svn+ssh:// like there is in svn://. It's my understanding that you could use a box which has no svn software installed on it as long as it has a correctly formatted repository and an ssh server. User access is controlled not through svn's built-in authz file, but via filesystem permissions and user accounts on that machine.
I might be wrong; as I mentioned, it's been a while - we use mod_dav_svn on Apache - but what you're describing differs from how I remember it.
Anyway, it's a bit of a tangent.
The legal consequences come in the form of corporate espionage. It's a very real problem that is rarely talked about at large. We talk about it a lot where I am because we have experienced it first hand. Although it's true that there's value in being able to prove when and why a change was made, and by whom; this wasn't what I was speaking about (and you're right, svnadmin commands mean that if you have administrative access to the repository, you can make it look like whatever you like).
Instead I meant to talk about being able to prove that my company developed a technology, and not a competitor who shows up on the scene with an identical offering (same code and everything). If we can produce revision history including bug fixes, feature additions, etc, while our competitor can only produce a single build and possibly changes after the date they illicitly acquired the code base, then we have the legal recourse necessary to shut that down.
If they steal a laptop with a SVN working copy on it, they get that version of the code but nothing else. If they steal a laptop with a git repository on it, they have all the same ability to produce complete revision history as we do. They also potentially get access to in-progress projects that the owner of the stolen laptop wasn't even working on.
Laptops can be legitimately stolen (guy's bag gets switched at a coffee shop he frequents every morning), or they could be stolen through espionage (we'll give you $30,000 if you "lose" your laptop in our favor).
With SVN we have the access logs on our server that shows who checked out what working copy and when. If someone wants to steal complete revision history and they're not an SVN admin, they're going to leave fingerprints all over that operation (one project is about 12,000 files and about 15,000 revisions; getting complete revision history for this is going to leave a very easy to find access pattern).
Don't get me wrong; git is fantastic, and certainly has many useful functions. The fact that you have a local copy of the complete repository (aside from disk space) is fantastic for offline work. The fact that it's distributed means that you don't have a single point of failure source control server, etc. There are just a handful of design decisions which make it a non-option for us.
Also, regarding authenticity of release tags; I'm not sure I get this point. We generate a tag (eg /tags/release_4.1.7e) at revision 15489; that then is the build number of the release. Unless you're an svnadmin, there's no way you could ever forge this; even if you deleted and recreated /tags/release_4.1.7e pointing at a different version of the code, the build number would still be wrong (as would the date), and the svn log would show who was trying to falsify a build. In addition for us, a specific service account creates the build and the release tag; so it would also have the wrong user ID. Users don't have access to tag in this space (in fact, we use tags for more than just releases, so we break from convention by making /tags/releases/2009/release_4.1.7e - with nearly weekly minor releases and monthly feature releases, this just makes it a bit easier to drill in), so again unless you're an svnadmin, you don't even have the capacity to try to forge a release no matter how obvious it would have been.
It's certainly true that the branching tools we wrote aren't specific to any given source control system; the git-vs-svn opening of my response was mostly just to point out that there's a better way to use SVN.
You might be right about svn+ssh being poorly documented; I never had a hard time getting it up and running, but most of the concepts were pretty familiar before I started, so I might not be the most representative. As to it being poorly supported, I'd be surprised; it's essentially filesystem access over an SSH tunnel. Local filesystem access is what you use when you want to debug things to know if it's a problem with your transport protocol or a problem with your repository. You don't have to use authz access, you can rely on disk permissions, and especially if you have root access this is extremely easy to debug any issues with.
You can do diffs while offline with SVN as well; inside the .svn folder is a text-base folder within which is an original copy of each file. You can't access revision logs, but you can compare local changes.
I know where I work, I can't go into a lot of details, but I can say that it would be unwise of us to use a source control system where each laptop contained revision history on it. There are certain things from a legal or a patent perspective which we need to be able to prove we're the original creators of. Source history is a good way to demonstrate this. If a competitor got access to a complete revision history, it could be a very expensive compromise. This is a major weakness for us for git or other distributed source control models, no matter the benefit such a system brings.
svn+ssh doesn't store anything in clear text. If that's a security concern for you, there's already a solution in place. Git is not the be-all and end-all solution to source control; it does many things very well, but there are a few things it does very poorly (repository control; with git, developers have a local copy of the repository which means that a stolen laptop comes with complete revision history). When the systems you're working on have certain sensitivities (legal, patent, security, etc), this can be a major weakness.
We do something very similar to the original submitter at work. We have 10-15 project branches open at a time. For us, we make sure that our code is subdirectory-agnostic (meaning it can run on the root of the website, or it can run out of a subdirectory). We use directory paths for branches, and we use internal DNS records for environments. http://de-appname/branchname would be a development branch while http://va-appname/branchname would be a validation branch.
For our lifecycle, we have development, validation, staging, pre production, and production. Development and validation are the only branching locations; staging, pre, and production are each single-path locations (though staging is a branch reserved for this purpose, pre production and production are /trunk)
On http://de-appname/ and http://va-appname/ there is essentially a directory listing along with the fully qualified branch name, revision, most recent contributor's name (even spelled out by looking up their record in LDAP), commit time, and most recent log message. Developers get a drop-down menu next to project branches which they can use to update the working copy there on that shared server (does a little ajax call and shows you the result in real time as though you were at a terminal). You can also create clean checkouts and even create new branches (either off of trunk or off of another branch). Finally you can even close a branch through this interface; it deletes the branch with a meaningful log message, and cleans up the files on that server. All through a web interface, no need to remotely log into a machine for this purpose. There's no reason for someone to administer this, each developer creates a working copy when and where he thinks it makes sense for himself.
Because our back end is SAP, we don't have to deal with multiple database environments. There's no "create a new copy of SAP" - indeed when this is something that's organizationally important (testing a major upgrade), it's a multiple day long process. We have a fixed set of data environments, and these are tied to hostname (going back to de-appname, va-appname, stage-appname, etc). If there were multiple database environments to worry about (eg, you wanted to be able to effectively branch database environments too), it wouldn't be a huge deal to set up a template database and have the same scripts we use to manage branches through a web API clone that database and update config in the appropriate app.
The key that I'm trying to get at is that you should create a web based tool to allow developers to manage this themselves. The developers will thank you because they'll be able to get what they want faster than you could have provided it, and they'll have control over when where and why working copies of their work in progress appear.
It would lower the barrier to espionage. You wouldn't have to beat your competitor to the market with their invention - which although this does happen, it's hard because you still have to get it to a patentable state without the benefit of having the minds in your employ which are producing the invention. So under the best circumstances you are still under a tight timeline (unless your competitor is delaying patenting, as happens for example in the pharmaceutical industry where the time between patenting a product and being able to sell that product is consumed by years of preclinical and clinical trials and regulatory approval periods).
Simultaneous invention clauses would let your competitor then even wait a month or two after you patent it to identify issues with your implementation that only appear when you start to put the product to real world use. Then they file their patent, and potentially lock you out of fixes to your own product when they make the case that invention of the fixes could not have been simultaneous because you only produced them in response to real world use, while their version had it all along (as their extensive though forged documentation proves).
How much time is too much time for independent invention to no longer matter? 1 year, 5 years? Anywhere within my patent life span someone could show up claiming independent invention and undo my patent. Two non-colluding inventors owning the same patent would effectively mean there was no patent.
I could go on. Letting two inventors own the same space has a lot of issues beyond just defeating the fundamental principles of patents. The point is a guaranteed limited monopoly in return for sharing the details of the technology with the world. Two competitors in the same space is not this.
I'm guessing this is a big part of why they don't honor independent simultaneous invention. It means that if you had a mole in a competitor's development space, they could secretly feed you enough data that you can reproduce the invention cycle on your own with only a slight delay.
Disregarding the inability to authenticate independent invention; if two inventors did have a patent on the same invention, then licensing becomes a bidding war for which inventor will offer a lower licensing cost. One of the main purposes of a patent is to allow an inventor to recover the cost of research & development; now these inventors would instead be in a position where they were trying to minimize loss.
They are in the business of selling a service meant to counteract software piracy. Any numbers they quote on the prevalence of same should be distrusted since they have a conflict of interest in reporting this accurately.
Even with all best intentions, they are likely to make educated guesses in their own favor rather than with a balanced perspective... and since their numbers aren't based on an actual desktop population sample, but extrapolated from other sources, then the possible accuracy is automatically highly suspect.
You're wandering out of my area of expertise, but the way I understand it, if it's a corporate deployment, it's possible to have an internal corporate app store, and I think it's even possible to push apps to phones (so they'll have an icon on their springboard for the training without having to go explicitly install it).
If you're talking about a public deployment, then you could push your app through the App Store like any other.
With Flash, you should be able to have it load training materials from an Internet server so that users don't have to download a new version each time training materials are updated, but I doubt you'll be able to play SWFs (for the same reasons Apple won't let Adobe put Flash on the iPhone); you'd have to have your app load an XML file with all the display instructions embedded and take care of rendering the display instructions yourself.
We built that sort of training app a few years back. The customer wanted to be able to have a single set of SWFs they could reuse by modifying the data. Made a nice little web interface to create new training program slides and quizzes; it spit out XML files and stored them on the server, then when you fired up the training app, it gave you a drop-down of all the training files it found on the server.
Yeah, there's no PM system here. I'm sorry to say I don't have any dead tree books to offer advice on. I learned ActionScript in the 1.0 days and have advanced my knowledge each time the language advances mostly through either in-program Help files or online documentation.
Today I'm working on connections to and passing data around in Flash Media Server. I'm working my way through examples in the documentation that comes with Flash Media Server, and Googling for more details on specific methods and their arguments (I don't just copy the examples verbatim, I try to fit the examples into the actual code base I'm working with).
Javascript is an OK language, but it doesn't really have anything ActionScript doesn't have. They're both based on ECMA Script, so the syntax is similar. They both have event systems.
ActionScript has strong typing as an option (though you can elect to go with weak typing if you wish), implicit getters and setters for properties (eg, function get foo():String { return this._foo; } function set foo(newFoo:String):void { if (newFoo != 'bar') this._foo = newFoo; }) which allow you to start adding data validation or trigger other behavior when you change a property. It's got method and property visibility controls. Class level constants, static properties and methods, interfaces, and a whole slew of other high-order OOP functionality that JavaScript is just missing.
I do quite a lot of work in both languages. Maybe it's a style choice, but I'm definitely a much bigger fan of ActionScript than JavaScript. Fortunately their domains do not overlap very much (and in fact I do quite a lot where the two talk with each other).
On a side note, not sure why my parent post got marked as Troll; I'm guessing someone has a beef with the politically based comments I posted yesterday in a different thread, and is trying to punish me here.
It's not a "last ditch effort" to remain relevant. It's just Adobe continuing the tradition of ubiquity of their platform. Apple won't let them put a runtime on the phone, so they'll deploy native code instead.
Sorry, but there's a big difference between an AJAX app and a native app. Try writing a browser based graphical game on the iPhone; it's going to fall on its face pretty quickly.
Hmm, convince developers to learn a whole new SDK for a single platform, when they can stick with a mature language and toolset they already know, deploy it in the browser, on the desktop (via Air), and on basically every phone on the planet that can run custom apps, including the BlackBerry?
Sorry, this whole article is bunk. Adobe isn't struggling with relevance, they're just making sure it doesn't start to slip, as Apple is so strongly trying to make it. In fact, this probably backfired on Apple a bit - Flash apps running as a native binary will probably have access to device functions which the normal Flash runtime wouldn't have.
I'm guessing this sale has already been made. A lot of developers like working in Flash. Actionscript is a surprisingly elegant language. Based on the number of Flash apps which already turn up all over the web, a whole new segment of developers are seeing this as access to a development platform which was previously closed to them.