Zed Shaw - The ACL is Dead - CUSEC 2008(blog.cusec.net)
blog.cusec.net
Zed Shaw - The ACL is Dead - CUSEC 2008
http://blog.cusec.net/?p=197
54 comments
Wow, the guy doesn't have horns!
He's actually really entertaining to listen to. I like his real-world examples of problems.
Steak will never be the same.
He's actually really entertaining to listen to. I like his real-world examples of problems.
Steak will never be the same.
Zed is going to become important. It's easy to write, but it's not easy to look good on video, as well as have good video timing. He's not perfect, but he's good.
If he sticks to his rant-personality, he will sooner or later become on of the stars of the internet.
If he sticks to his rant-personality, he will sooner or later become on of the stars of the internet.
Personally I don't see who can compete even now. Zed's blog is the only blog RSS feed I have in my reader. Nobody else has earned the privilege so far. Everything else in my reader is corporate stuff like HN or arstechnica.
I love that he's saying "The ACL is Dead." This should be said loudly and often. Maybe it'll get through the heads of management out there. Heck, it needs to get through the heads of a lot of programmers.
Modern security and access controls need functionality like capabilities.
Modern security and access controls need functionality like capabilities.
Any links? As only a sometime-programmer, the "ACL is Dead" idea is new to me. I could use some good examples.
Zed Shaw discusses this in several parts within the presentation; it's somewhat of a recurring theme.
ACLs as they're implemented on most operating systems are wicked limited; tracking attributes and access to anything beyond simple boolean HAVE_ID or !HAVE_ID or HAVE_THIS+HAVE_THAT logic gets really ugly with an ACL. And the classic ACLs are not at all dynamic, as is pointed out in the presentation. You can't easily tie the access control processing directly into the LDAP directory for employment status or into the system time for time-based rules, for instance.
Having access to conditional statements and such to manage access control is infinitely more flexible. This is the "Turing Complete" part of the presentation.
This processing all reminded me of what you can do with D inside the DTrace environment, too. But I digress.
Watch the presentation. It's worth your time.
ACLs as they're implemented on most operating systems are wicked limited; tracking attributes and access to anything beyond simple boolean HAVE_ID or !HAVE_ID or HAVE_THIS+HAVE_THAT logic gets really ugly with an ACL. And the classic ACLs are not at all dynamic, as is pointed out in the presentation. You can't easily tie the access control processing directly into the LDAP directory for employment status or into the system time for time-based rules, for instance.
Having access to conditional statements and such to manage access control is infinitely more flexible. This is the "Turing Complete" part of the presentation.
This processing all reminded me of what you can do with D inside the DTrace environment, too. But I digress.
Watch the presentation. It's worth your time.
ACLs (and RBAC, and most capability security models) are limited for a reason -- they allow you to prove that certain security properties will hold for your application. Without a solution to the halting problem, no such assertion can be made about security mechanisms expressed using Turing-complete languages.
That's not to say that ACLs are the last word -- they were defined and analyzed in depth in the 60s and 70s, and work in security theory marches on. Models such as information flow analysis, object capabilities, etc., allow for much richer policy definition while still making stronger guarantees about the security of the finished system.
While I actually like most of what Zed has to say in this talk, I think he's doing a grave disservice to the security theory community by dismissing out of hand everything they've done in the last 40 years.
That's not to say that ACLs are the last word -- they were defined and analyzed in depth in the 60s and 70s, and work in security theory marches on. Models such as information flow analysis, object capabilities, etc., allow for much richer policy definition while still making stronger guarantees about the security of the finished system.
While I actually like most of what Zed has to say in this talk, I think he's doing a grave disservice to the security theory community by dismissing out of hand everything they've done in the last 40 years.
Yes that provability is big - but I guess is his point is that with SOX and other legal requirements - that provability and applicability of ACLs is now completely out of the window, so its time to stop hammering the square peg into the round hole.
Laywers and the law don't care about provable security models and neither do the gold owners who want the system. Zed is absolutely right, build what they want even if it isn't provably secure. Test it sufficiently, cover all the cases you can, and move on.
Something doesn't have to be provable to work, the same applies to type systems. Lot's of things that aren't provable and would be forbidden by a static type system will happily chug along just fine in a dynamic system that does what you tell it.
When it's law vs theory, law wins. Unlike theory, the law doesn't have to make sense but you sure as hell better be able to show that you attempted to comply with it.
Something doesn't have to be provable to work, the same applies to type systems. Lot's of things that aren't provable and would be forbidden by a static type system will happily chug along just fine in a dynamic system that does what you tell it.
When it's law vs theory, law wins. Unlike theory, the law doesn't have to make sense but you sure as hell better be able to show that you attempted to comply with it.
Thanks -- I did watch the presentation (http://news.ycombinator.com/item?id=420974) and I get how ACLs could be heavyweight and inflexible -- what I'm looking for are some concrete examples of how else people do it.
For example, does Ruby on Rails offer some framework for dealing with this? Or is it a 'just do it' kind of thing? Maybe it's not as complicated as I'm imagining it could be, and that's the point. But some example code would be good to look at.
I'll look into this further but thought I'd solicit here first.
For example, does Ruby on Rails offer some framework for dealing with this? Or is it a 'just do it' kind of thing? Maybe it's not as complicated as I'm imagining it could be, and that's the point. But some example code would be good to look at.
I'll look into this further but thought I'd solicit here first.
His comment about it turning into 500 lines of code isn't an exaggeration, most likely. The truth is that it's so simple that one can hardly understand why anyone uses ACLs after you've implemented something like this. You create a series of functions that define the attributes you are interested in, there's some lightweight context maintenance, then in the core of the system (the "500 lines") you simply tie all the pieces together in accordance with the business rules. It's so simple it almost boggles the mind. Bog-standard refactoring will get you there in nothing flat, and of course you have full Turing-complete language constructs at your disposal.
One hint: Write the code in a functional style, i.e., Haskell style. Pass in the full context to the permission function. For instance, if you have a time-sensitive function, don't have the time-sensitive function call the system clock; have it extract the time from the context your provided. If you call the system clock, you'll never be able to write the tests you're going to need to write. Similarly for many things, like direct LDAP access or whatnot. The internal permission code needs to be a pure function. Fortunately, that doesn't make it any harder to write, even in an OO-based language.
If you want to get really slick because your context has multiple expensive operations like direct LDAP access (although this is a bad idea if you're going to be calling this frequently), you can even create two context implementations, one for testing that simply returns provided values and one that lazily goes out and gets LDAP data or whatever if you need it. Best of all worlds that way.
One hint: Write the code in a functional style, i.e., Haskell style. Pass in the full context to the permission function. For instance, if you have a time-sensitive function, don't have the time-sensitive function call the system clock; have it extract the time from the context your provided. If you call the system clock, you'll never be able to write the tests you're going to need to write. Similarly for many things, like direct LDAP access or whatnot. The internal permission code needs to be a pure function. Fortunately, that doesn't make it any harder to write, even in an OO-based language.
If you want to get really slick because your context has multiple expensive operations like direct LDAP access (although this is a bad idea if you're going to be calling this frequently), you can even create two context implementations, one for testing that simply returns provided values and one that lazily goes out and gets LDAP data or whatever if you need it. Best of all worlds that way.
Thanks. Nice to have a sketch of the thing's structure. It's a finite state machine, where the 'attributes' are the states, and the code is the transition rule.
Test harnesses for this -- hm.
Test harnesses for this -- hm.
[deleted]
Notes from lunchtime viewing of first 40 min
------------------------------------
~9:29: "law is actually kind of a turing complete language"
Law is fuzzy; ACLs are fuzzy. ACLs can't handle real law because they're not Turing complete.
~11:20: had a business manager learn Ruby, had him implement poorly specified/tough features --> result: he modified/eliminated requirement
~12:20: a bunch of if statements are easier & better than an ACL
~13:50: in one case, 1000 users and 1000 containers would have required 270,000 ACL entries to implement one compliance rules; and 5 minute polling updates, because rule was time-based; --> couldn't audit, handle real-time changes; would've required 12 beefy boxes to execute.
14:40: Instead, re-write all rules in 400 lines of Ruby; analysts could read the code and say if implementation was right.
15:45: So a language wins, right? No -- "this is where the Suck begins" -- where management comes and crushes your soul. Bad product was substrate for document management system.
17:50: How do they sell this stuff? Connections, subterfuge? No.... "Steak and strippers, baby."
19:00: "This is one reason I want women to be in charge."
20:00: "What happens when they give you an MBA is they give you a lobotomy... and you walk out going 'Synergy! Synergy! Synergy!'"
21:00: MBAs are trained in manufacturing -- programming is not manufacturing -- you're going to work in an environment where they think you're worker bees on an assembly line.
22:00: So what to do about it?
1) Managers see people sitting there, they think nothing is going on. If management says "I demand all of your creativity but trust none of your judgement," you have to gather evidence that makes you more credible. You have to be objective. Try out whatever crappy technology that they're proposing.
2) Develop alternatives: if their crappy technology is good enough, stop; but if not, try out alternatives before suggesting.
3) Statistics; develop some pretty graphs. E.g., Zed's team built a demo server, showing slow performance. Without those, he would've had no evidence to contradict the sysadmin who was saying his tweaks had helped. Be prepared for intensely technical arguments, too.
4) Admit technical deficiencies.
~29:30: If none of this works, and they won't take it, build it anyway and then sell it to them or their competitors. The client can be your first customer. Good way to start a company.
~30:00: our doc management system is very simple, 4400 lines of Ruby plus some Samba modifications, and better than anything else out there.
Drools -- JBOSS rules engine -- "blows ass" -- just use Ruby instead.
~31:30: Figure out Roles first, with a Role Resolver -- draws on LDAP etc. -- 30 lines of Ruby -- now, ~200 lines of Ruby, covers all bizarre corner cases, easy to add new rules, easy to fix existing rules.
~33:30: And they still wanted the crappy older thing. At this point, it's all the social problem. What mattered was the old product had the same name. "Document Store 2000" vs. "Document Store New Gen" -- completely different, but easier to get through manager's manager's procurement process -- "that's the stupidity you deal with in the real world".
35:15: How do we win? We kept hammering. They sent out their best guy. I had him implement the toughest rule, the one requiring 200,000 ACL entries. Then had him explain to his managers why it wouldn't work. Had nothing to do with tech.
36:15: This stuff will kill you. How do you keep your soul through all of this? [Poll audience for years of education] -- "It don't matter" -- you're a factory worker.
37:30: "Business leaders don't really like you, because they need you, and they don't understand anything you do. ... And the sales people know this; they know if they go to your boss, and give them steak and strippers...."
~38:40: Fight your hardest not to be a corporate coder: your life as a geek or a coder should be all about exploring some new domain that no one else gets -- you can only go to conferences and talk to other geeks about what you do. A corporate coder works only on the stuff he's supposed to on one language, and never touches code otherwise. You should go home and do something fun with technology.
40:00: how to avoid not getting burnt out by day job? I.e., how to avoid losing your soul?
[40:30 stopped watching, back to work.]
------------------------------------
------------------------------------
~9:29: "law is actually kind of a turing complete language"
Law is fuzzy; ACLs are fuzzy. ACLs can't handle real law because they're not Turing complete.
~11:20: had a business manager learn Ruby, had him implement poorly specified/tough features --> result: he modified/eliminated requirement
~12:20: a bunch of if statements are easier & better than an ACL
~13:50: in one case, 1000 users and 1000 containers would have required 270,000 ACL entries to implement one compliance rules; and 5 minute polling updates, because rule was time-based; --> couldn't audit, handle real-time changes; would've required 12 beefy boxes to execute.
14:40: Instead, re-write all rules in 400 lines of Ruby; analysts could read the code and say if implementation was right.
15:45: So a language wins, right? No -- "this is where the Suck begins" -- where management comes and crushes your soul. Bad product was substrate for document management system.
17:50: How do they sell this stuff? Connections, subterfuge? No.... "Steak and strippers, baby."
19:00: "This is one reason I want women to be in charge."
20:00: "What happens when they give you an MBA is they give you a lobotomy... and you walk out going 'Synergy! Synergy! Synergy!'"
21:00: MBAs are trained in manufacturing -- programming is not manufacturing -- you're going to work in an environment where they think you're worker bees on an assembly line.
22:00: So what to do about it?
1) Managers see people sitting there, they think nothing is going on. If management says "I demand all of your creativity but trust none of your judgement," you have to gather evidence that makes you more credible. You have to be objective. Try out whatever crappy technology that they're proposing.
2) Develop alternatives: if their crappy technology is good enough, stop; but if not, try out alternatives before suggesting.
3) Statistics; develop some pretty graphs. E.g., Zed's team built a demo server, showing slow performance. Without those, he would've had no evidence to contradict the sysadmin who was saying his tweaks had helped. Be prepared for intensely technical arguments, too.
4) Admit technical deficiencies.
~29:30: If none of this works, and they won't take it, build it anyway and then sell it to them or their competitors. The client can be your first customer. Good way to start a company.
~30:00: our doc management system is very simple, 4400 lines of Ruby plus some Samba modifications, and better than anything else out there.
Drools -- JBOSS rules engine -- "blows ass" -- just use Ruby instead.
~31:30: Figure out Roles first, with a Role Resolver -- draws on LDAP etc. -- 30 lines of Ruby -- now, ~200 lines of Ruby, covers all bizarre corner cases, easy to add new rules, easy to fix existing rules.
~33:30: And they still wanted the crappy older thing. At this point, it's all the social problem. What mattered was the old product had the same name. "Document Store 2000" vs. "Document Store New Gen" -- completely different, but easier to get through manager's manager's procurement process -- "that's the stupidity you deal with in the real world".
35:15: How do we win? We kept hammering. They sent out their best guy. I had him implement the toughest rule, the one requiring 200,000 ACL entries. Then had him explain to his managers why it wouldn't work. Had nothing to do with tech.
36:15: This stuff will kill you. How do you keep your soul through all of this? [Poll audience for years of education] -- "It don't matter" -- you're a factory worker.
37:30: "Business leaders don't really like you, because they need you, and they don't understand anything you do. ... And the sales people know this; they know if they go to your boss, and give them steak and strippers...."
~38:40: Fight your hardest not to be a corporate coder: your life as a geek or a coder should be all about exploring some new domain that no one else gets -- you can only go to conferences and talk to other geeks about what you do. A corporate coder works only on the stuff he's supposed to on one language, and never touches code otherwise. You should go home and do something fun with technology.
40:00: how to avoid not getting burnt out by day job? I.e., how to avoid losing your soul?
[40:30 stopped watching, back to work.]
------------------------------------
Thanks for posting this; the part at 40:00 actually motivated me to view the rest, which I recommend to anybody working in a corporate job.
Hopefully this summary does justice to the remainder (but IMO it's worth watching):
40:00 Essentially he says you're not defined by your job. Your outside projects represent your self-expression and the corporation doesn't get a piece of that.
42:00: Most companies treat programmers like factory workers. In that case, act like one: do a professional job and punch out at the end of the day.
43:30: "If the company makes money off the sweat off your back, you get a chunk. If you don't get a chunk then you give them what they absolutely ask for, keep it to a minimum, be friendly, be very professional, do your stuff, make sure it's well-written, but don't go out of your way to give them your latest, greatest research or your idea or whatever."
44:00: Work on weird and cool stuff at home to stay sharp. If all you do is corporate coding, all you'll ever be is a drone.
45:00: When you're coding at home, "you're making poetry people can play with." But you don't want to do this for a company that doesn't care. "Who wants to make another document management system, time tracker or accounting system? There is money in that, but unless you're making the money too, it's not really fair."
47:30: Don't fear change. At home, take chances and learn new stuff. But at work, just give them what they want because they'll make changes whether you like them or not. It's just a job.
50:00: If you're concerned about being outed, consider creating an online identity (like "_why").
51:30: Don't do Blub at home; do something completely different, break the rules and code for fun. At work, don't think too much, don't be different and just get it done.
52:40: Outside work, make sure you're not someone's "resource" to be "utilized." Run with like-minded folks.
54:00: Embrace your geekiness, get out there and do it now.
55:00+: Questions and answers. This was good too, but somebody else will have to take over the transcription. ;)
Hopefully this summary does justice to the remainder (but IMO it's worth watching):
40:00 Essentially he says you're not defined by your job. Your outside projects represent your self-expression and the corporation doesn't get a piece of that.
42:00: Most companies treat programmers like factory workers. In that case, act like one: do a professional job and punch out at the end of the day.
43:30: "If the company makes money off the sweat off your back, you get a chunk. If you don't get a chunk then you give them what they absolutely ask for, keep it to a minimum, be friendly, be very professional, do your stuff, make sure it's well-written, but don't go out of your way to give them your latest, greatest research or your idea or whatever."
44:00: Work on weird and cool stuff at home to stay sharp. If all you do is corporate coding, all you'll ever be is a drone.
45:00: When you're coding at home, "you're making poetry people can play with." But you don't want to do this for a company that doesn't care. "Who wants to make another document management system, time tracker or accounting system? There is money in that, but unless you're making the money too, it's not really fair."
47:30: Don't fear change. At home, take chances and learn new stuff. But at work, just give them what they want because they'll make changes whether you like them or not. It's just a job.
50:00: If you're concerned about being outed, consider creating an online identity (like "_why").
51:30: Don't do Blub at home; do something completely different, break the rules and code for fun. At work, don't think too much, don't be different and just get it done.
52:40: Outside work, make sure you're not someone's "resource" to be "utilized." Run with like-minded folks.
54:00: Embrace your geekiness, get out there and do it now.
55:00+: Questions and answers. This was good too, but somebody else will have to take over the transcription. ;)
I haven't personally worked there, but from everything I know I have to second his idea that you shouldn't work for a big huge video game company (chiefly EA) because you like games and want to make your own. If you have the capital and the skills to make games on your own and/or with a few friends, go for it! The late 2000s are proving to be a sort of golden age of indie gaming from both ends of the transaction.
edit: Also, unrelated to this, another question/answer pair starts around 66:00 which I think is a pretty good idea.
edit: Also, unrelated to this, another question/answer pair starts around 66:00 which I think is a pretty good idea.
Q&A was good - I think Zed is wildly missing the non technology/boring business aspects of starting up (I guess he hasn't tried to start something up before? Or maybe he has...).
Reading your post and considering it further, I guess his message is less about starting up than about how to survive a day job and continue to grow as a human being by doing interesting work at night.
Blub work on a startup at night could be another path away from employment that isn't really addressed in the presentation (though it's very difficult to pull off, IMO).
Blub work on a startup at night could be another path away from employment that isn't really addressed in the presentation (though it's very difficult to pull off, IMO).
It's strikes me that his advice on how to avoid getting burnt out at work is advice that is precisely designed to ensure that your day job is boring, unfulfilling and that you never get given any tasks that are interesting or designed to let you stretch your intellectual wings.
possibly - I watched probably 80% of the presentation, so I might have missed some nuances. My brief experience with startups showed me the last thing you worry about are tech choices and if you are in blub or not, more along the lines of "holy shit holy shit they won't pay that bill". But that was sometime back, startups now seem like a whole lot more fun (maybe thats VC backed ones were you aren't focusing on cashflow up front??).
[deleted]
Well I think his audience is "corporate programmer" types isn't it? cause what he says is just confusing to the rest of us.
Actually his audience are people who happen to have days jobs as corporate programmers. The difference is both small and large.
Right - yes understood.
I guess the actually title of his talk is less interesting to most (but its good for people to realise ACLs and such are just not practical anymore - its a worthy talk subject !). I think I discovered that about ACLs a while ago, but assumed it was a specific problem with whatever I worked on, not that its a general issue with the ACL approach.
I guess the actually title of his talk is less interesting to most (but its good for people to realise ACLs and such are just not practical anymore - its a worthy talk subject !). I think I discovered that about ACLs a while ago, but assumed it was a specific problem with whatever I worked on, not that its a general issue with the ACL approach.
on "steak and strippers...." - well I think there is a fundamental misunderstanding - ALL input products (not just software based) is sold this way to large corporations. Everyone has an agenda.
Also - its not just big enterprisey things - rails is so common in the enterprise these days due to the "steak and strippers...." work done by companies like thoughtworks. There is always wheeling and dealing, even with grassroots things - things are never as white and as pure as they seem (well almost all things).
I don't see this ever changing, unless somehow all these types of corporations simultaneously cease to exist, and something else more merit based takes their place.
Also - its not just big enterprisey things - rails is so common in the enterprise these days due to the "steak and strippers...." work done by companies like thoughtworks. There is always wheeling and dealing, even with grassroots things - things are never as white and as pure as they seem (well almost all things).
I don't see this ever changing, unless somehow all these types of corporations simultaneously cease to exist, and something else more merit based takes their place.
There was a story on HN several months ago about a guy on vacation in Istanbul having someone sell him a rug even though he never had any intention of getting one. It outlined a whole lot of non-bullying sales tactics that had nothing to do with the actual product, it was more about putting a person in an environment and state of mind where they felt like getting the product, even if they never really wanted it.
"... it was more about putting a person in an environment and state of mind where they felt like getting the product, even if they never really wanted it. ..."
Or by stimulating the neural cortex with sound to prime you to purchase. This is the idea behind pumping music into shops. Just another technique in the toolset to make you buy, "Why We Buy: the science of shopping" ~ http://www.abc.net.au/catalyst/stories/s1907307.htm
Or by stimulating the neural cortex with sound to prime you to purchase. This is the idea behind pumping music into shops. Just another technique in the toolset to make you buy, "Why We Buy: the science of shopping" ~ http://www.abc.net.au/catalyst/stories/s1907307.htm
Exactly - salesmenship? (is that a word?).
So is zed proposing a world where there are no sales people?
I guess some people may point to things that "sell themselves" like apples consumer products where people camp out to get them.
Sure - but how did apple really get strong enough to survive this long? at least in this country it was steak and stripper sales to the education department to get them in all schools.
Sure - but how did apple really get strong enough to survive this long? at least in this country it was steak and stripper sales to the education department to get them in all schools.
I wonder what is the other side of "steak and strippers, baby!"? Why is it that management doesn't trust us? He says a little about it: "You guys have got to stop lying...talking on IRC all day..." I wonder if it's all because of dopplegangers, or the techie dark side?
A part of it is because we're different. But a part of it must be bad as well. We're all only human, after all.
A part of it is because we're different. But a part of it must be bad as well. We're all only human, after all.
Well its pretty clear to those outside the industry as well as in it that this is totally a fashion industry - we behave like spoiled prima donnas at times. Can you blame them? Zed only makes this more obvious to them - they wouldn't look much deeper into what he says anyway.
Immediately after 40:30 is actually the best part of this talk.
I thought the opposite. The real life example of implementing his project was a lot more interesting than yet another exhortation to "be true to yourself".
The misconceptions that some technical people have about MBAs are kind of funny, but also rather pathetic. The program I went through put very little emphasis on manufacturing.
Lots of stuff here that resonates with this some-time CMS architect and soulless corporate wage slave, but I missed the part where Zed was able to provide an easy-to-use UI to allow non-programming sysadmins to change the security rules. That must have been so simple he didn't need to mention it, right... right?
No, but he is saying that complex things require an actual language, not a point and click UI idiots can use, so changes to rules would require a programmer.
Seriously, the idea that a complex system can be built by non programmers is somewhat of a pipe dream, it always ends up being more complex than some simple code a programmer can understand.
Seriously, the idea that a complex system can be built by non programmers is somewhat of a pipe dream, it always ends up being more complex than some simple code a programmer can understand.
I agree wholeheartedly with your last statement, but my point was that Zed got through the whole hour without once mentioning that this was a trade-off that was being made - and it is a pretty important one.
(Also, non-programmers != idiots)
(Also, non-programmers != idiots)
It was not a trade off being made. The point and click UI could no longer meet the requirements. That's what he was getting at saying the legalese was turing complete. The requirements the law now mandated required an actual language to to implement because the old system with ACL's can't do the job anymore.
That the new system doesn't have a point and click UI isn't a trade off, it's just a consequence. He wasn't trading a complex system for a simpler system, he was replacing a complex system that could no longer work with a simpler one that could.
And while not being a programmer doesn't mean you're an idiot, not being able to learn some simple scripting to modify rules does make you an idiot. If your job requires you to modify the rules, and you can't learn to do it, you're dumb. All intelligent people are capable of learning some simple scripting.
That the new system doesn't have a point and click UI isn't a trade off, it's just a consequence. He wasn't trading a complex system for a simpler system, he was replacing a complex system that could no longer work with a simpler one that could.
And while not being a programmer doesn't mean you're an idiot, not being able to learn some simple scripting to modify rules does make you an idiot. If your job requires you to modify the rules, and you can't learn to do it, you're dumb. All intelligent people are capable of learning some simple scripting.
yeah it sounded like a compromise - obviously an acceptable one, but it was brushed over.
I wish I could see his slides.
It's in Factor, right?
Is the source available?
Is the source available?
I can't seem to figure out how to run this... I downloaded the OS X distribution, opened it, selected "Run..." from the File menu, and selected the cusec2008.factor file. Now what?
Make a 'cusec2008' directory in the distribution's `work' directory, and put the .factor file there. Open the factor runtime, type
USE: cusec2008 start-presentation
and then hit enter. No, not the most user friendly of processes. But I suppose it's the price you pay for being the indiest of indie.
USE: cusec2008 start-presentation
and then hit enter. No, not the most user friendly of processes. But I suppose it's the price you pay for being the indiest of indie.
Why was this downvoted? I'm asking a legitimate question.
Probably because it's explained on the video page:
http://vimeo.com/2723800
If you are still having trouble try:
http://vimeo.com/2723800
If you are still having trouble try:
USE: cusec2008
start-presentationLovely, thank you.
This whole "must follow speaker with camera" thing has _got_ to stop. Just stick the camera on the slides and leave it there. _At least_ get both in the frame. This is pushing unwatchable with him pointing to the slides all the time, the audience laughing at the slides, he's referring to code on the slides... Kill me :/
Hey that sounds like a neat camera product idea: how common is it that you want to record 2 visuals at once? Pretty common - so a little camera with 2 separate point-able lenses would be nice - or something like that.
Zed Shaw: Joe Hill of programming. Though rather than organizing workers into unions/factions of the IWW he is advocating people reserve their "real" programming/creativity for themselves unless they stand to make a profit (which they would if labor conditions were equitable). I can totally get behind that.
fucking awesome
N.B. This video might damage your vision of Zed swearing all the time and may make it seem like the last year of ranting was a terrible joke gone wrong. Oops.
P.S. - Check out this year’s lineup (Ingalls, Stallman, Bryant, Culver, Hwang, and Bowkett are just the keynotes). This is one of Canada's best kept secrets, and tickets are super cheap.