It does maintain old copies of files. For 30 days, files you delete can be restored, and you can revert files to earlier versions. For a fee (an add-on called PackRat), they will keep old versions and deleted files indefinitely.
Dropbox lets you restore deleted files (or return to earlier versions of the files) for a certain amount of time. And for a fee, they keep deleted / version history indefinitely (called Pack-Rat).
If Dropbox's services are still online, you can take advantage of this. If Dropbox's services go offline, then the edits and deletes aren't synced anyway, and you still have a layer of redundancy (though you need to find a new solution for new data).
I agree that it's still not quite backup, but it is very close and completely fuss-free.
Absolutely. I have 4 dual core CPU's in my machine. When I encode video, all four are clocking at about 90-95%. Encoding an hour of video takes in the neighborhood of 10-15 minutes per pass depending on the movie, and my hardware is even a few years old, plus I'm typically decoding at the same time from a different source (eg, DVD).
Phones make a terrible book device. Bad enough that the headline on Apple's site is "The Textbook. Reinvented for iPad," not iOS. Not a single iPhone even makes an appearance on either the Textbook page or the iBooks Author page. There are plenty of iPads though.
How many iPads are out there compared to Kindles? I'd be VERY surprised if there are more $500 devices out there than $80 devices. It takes a lot more book discounts to make up for a $500 price tag than an $80 price tag too.
Sorry, "Well, if you're a REAL geek, you'd just reverse engineer the closed format" is a terrible way to excuse proprietary formats. Might as well not HAVE open formats if that's the bar for what's acceptable in the realm of openness.
It claims support for it, and it does not have problems with the ePub3 test books from http://azardi.infogridpacific.com/html/resources.html . I've looked in the new files. They're full of stuff like <object type="application/x-ibooks+shape" id="textShape-2" data-original-id="textShape-90"> and css with -ibook- prefixes.
Seriously, you've replied to me in several spots aggressively defending Apple's lock-in. Have YOU tried this in different readers? Do YOU know of a non-Apple reader which can display Apple's new book format cleanly? Maybe Apple is just really ahead of the curve in terms of formatting while maintaining compliance with the standard. But the proprietary extensions loaded in these books suggest otherwise. It's all very Microsoftish, embrace and extend.
It's all moot anyway, Apple's TOS says you can't sell a book created for iBooks through anyone but them, and only if they choose to let you (i.e. they approve of your content), and it can't cost $15 or more (that last one I actually think is not too shabby for the vast majority of cases). They can't lock you to sell only on their platform by technical means like they do with iOS apps (where you have to pretty much independently develop multiple times if you want to target multiple platforms), so they'll just produce lock-in via a licensing channel.
At least the content is accessible, I should be grateful that it's not completely locked away. Future historians will be able to access the contents of these files when Apple's licensing servers have died. Except when they're DRM encrypted, then the future is SOL.
I see ePub with a pile of proprietary extensions; it's barely an ePub at all since most of the formatting gets lost to any reader but Apple's. Almost might as well have been a.txt file, except much, much bigger.
(ii) if your Work is provided for a fee (including as part of any subscription-based product or service), you may only distribute the Work through Apple and such distribution is subject to the following limitations and conditions: (a) you will be required to enter into a separate written agreement with Apple (or an Apple affiliate or subsidiary) before any commercial distribution of your Work may take place; and (b) Apple may determine for any reason and in its sole discretion not to select your Work for distribution.
So even though it's a (horribly broken) form of ePub, it doesn't matter, you're not allowed to sell it to anyone without an iDevice, only if Apple chooses to let you, and you get to pay Apple for this privilege privilege.
It's about iPad because only iPad and iPhone can read the ibook format.
I downloaded iBooks Author and published a book to experiment with. I chose one of their templates, picking the one which seemed to have the fewest by way of zany formatting or artwork.
Although the file produced has a ".ibooks" extension, it looks like under the hood this is ePub at the heart, but with a pile of proprietary extensions on top. I renamed my published file to have an.epub extension, and loaded it up in my ebook reader. The text is readable, but the formatting is all gone. There are image assets floating around occupying space where text should be, but they were background images in the ibooks version, while here they're interfering with text flow. I'm guessing these images are responsible for the 1mb file size for a 3 page book too.
So the format may be ePub, and although the content isn't completely locked away, I might as well have published a.txt file, at least then it wouldn't be littered with garbage images. If this is an attempt to comply with existing book readers (in the spirit of the open format), it's at best a token attempt. This looks like it would be a great editor, if it was useful outside of the Apple iMpire.
Unfortunately this is a terrible time to be trying to make money off the primary education market (where government money is). Secondary education is great because kids are buying their own equipment, usually financed by their parents, and lots and lots of kids are going to college who have no business doing so. But that's typically private money, not government money.
In primary education, budgets are being cut left and right. Maybe some upper class schools will be providing iPads for their students, or private schools which require this as part of admission. But in typical public schools, the teachers and parents would revolt. You're cutting after school programs, gifted and special education, and cutting teacher heads, but you have money to buy a bunch of GADGETS?!?
iPads for primary education are terrible. They are a distraction for students; you can do too many unrelated activities on them, and are easily destroyed. If a student loses an entire bookbag full of books, the replacement costs are probably less than losing this single fragile high-theft-target device.
I don't see any mention of that on Apple's site that it's ePub. Maybe I missed it, can you give me a link that confirms this?
From what others have been saying, you can export to only one of 3 formats, their proprietary format, PDF (non-interactive, fixed page format, basically not an ebook format at all), and plain text.
It's not like we need another freaking proprietary book format. Maybe their new format has support for things existing formats don't, but books created in this software should be exportable to other open book formats such as ePub. They're not, this is just Apple trying to control a new market and claim a 43% markup on all digital book sales.
They're a bit late to this game, Amazon is pretty entrenched with Kindles already in most people's hands, and at prices which are far more approachable than iPads. It takes a lot of FREE (beer) books to make up the purchase cost of an iPad, and most books aren't free [beer].
There are a handful of times where goto is simply the most elegant solution, and a handful of times where performance really matters, so encapsulating logic into a function to avoid a goto will be too costly. I've used it once since my high school BASIC days; interestingly it was only a few months ago.
We had a costly operation working against arbitrary precision numbers, with some nondeterministic aspects. Part of the data produced is very publicly visible, and because of the nondeterministic aspects of things, we had an incident where some undesirable output was produced (valid by system design, but humans found it offensive). So rather than restart the whole operation to let the nondeterministic side of things produce something more desirable, we want to change just a chunk of the data and jump back into the middle of things to recompute the downstream results.
I know I'm being vague, I have to be. I wrote the procedural equivalent, and not only did it separate tightly related logic, the performance cost was significant at this scale, even for the non-exception scenarios, and the amount of markup to support it was prohibitive. It also actually upped the CRAP score (which was already unusually high because the focus was on performance optimization). The goto alternative was literally two lines: one label and one goto, and introduced essentially no overhead for the most common use case (the vast majority of the time the produced data contains nothing offensive).
I'm still embarrassed by it, but even now going back and looking at it, I'm not sure how I would do it in a more readable or performance equivalent manner. I made sure to include a link to this comic in the source next to it, along with a clear description of why that was the path chosen over a more traditional approach.
I could be that I just fundamentally structured the flow wrong. Maybe there there was a better path through this. My team mates ribbed me for using the goto, but agreed that it was both more readable in the end, and observed the performance cost of the alternate approach; a rare exception was made in code review to allow this.
Would it make you feel better if I said "access content" instead?
My point wasn't about debating the definitions of "consume" and "content" (I specifically mentioned that I wasn't interested in debating definitions of words). My point was that she doesn't want Flash. She wants access to content which requires Flash.
It's the difference between saying, "I want to watch a movie" and "I want to use my DVD player," or the difference between "I want to go to the store" and "I want to depress the accelerator in my car." Both are technically true, but your primary desire is to watch the movie, not to manipulate the DVD player. The latter is only a means to an end, and if there's a different means to the same end (eg, Netflix, or public transit), that'd be fine. This is the same as having a tablet which runs Flash is for my wife; if she could access the same content in a different manner, she wouldn't care that it was Flash or something else.
I know this is a pretty late response, but for some reason I came back to this comment to respond. Normally I'm not that interested in being pulled into debates of nomenclature, but this one has been on my mind for a few reasons, so I figured I'd clarify.
It's just "she wants to use flash" or "she wants flash to run on her tablet" or some other simpler english, pretty please!!!!!
Actually that's not true. She doesn't care about Flash. She wants Flash on her tablet only in a round-about sense.
What she wants to do is "consume content" meaning use websites or web apps (I see some people got in a fight about what 'consume' and 'content' mean below, so I'm just clarifying since I'm not looking to get into a fight about definitions of every-day words). This content requires Flash. She doesn't want Flash, she wants the content. What she knows is that my tablet can show her this content, and her iPad can't. She's aware that the difference is Flash or not only because I told her so.
When she was looking at getting a tablet, I had warned her that the iPad can't do Flash, and she didn't really get what that meant, and didn't really care. She, like many, figured if it was important enough, there was a path to it on iDevices. She didn't count on being collateral damage in a turf war which isn't even about technology.
So I'll stick to my original statement as being closest to the truth. She wants to consume content which requires Flash. It's true that she wants Flash to run on her tablet, but this is an effect of the original statement, it's not a primary desire, the primary desire being wanting to consume that content.
Compare that to me: I want my tablet to run Flash, because I don't like someone making arbitrary decisions about what I can or cannot do with hardware I own. I actually care less about the content than she does, if I want it badly enough, I'll save it for later and look at it on my laptop or desktop. If it's not worth the effort of saving it for later, I didn't want it that badly anyway. Most of the time I don't really care that much if there's something about the content that it won't work. Most of the time when I see the Flash activation panel (I have it set to load on tap, not automatically), more often than not I just ignore it anyway.
I agree that Google as a whole is responsible for the actions of its individual branches, but it's how Google responds to the accusation that determines whether Google condones the behavior, not whether Google was able to proactively micromanage branch offices.
I don't buy your theory that because an Indian call center was involved, this automatically makes it an action blessed by corporate. Branch offices have their own budgets and discretionary spending. Maybe it was Eric Schmidt himself who told them to do this. But we really have no way of knowing, and it's a simpler explanation that one or a few employees were engaged in taking shortcuts than that Google corporate issues orders to branch offices which involve instructions to illegally misrepresent a business relationship.
Or maybe it was the Indian call center themselves who took this "initiative" and decided to lie about the relationship (that would certainly be consistent with when we fired a call center for overtly lying to our customers to shorten call times).
I'll side with Occam's Razor on this. If corporate wanted this information this badly, they'd have paid for it. The bad press and legal repercussions would outweigh the licensing costs.
Note the key words, "Google Kenya" - this is a branch office where some employee is taking a shortcut. This is hardly a condemnation of Google as a company unless and until it's demonstrated that this is either more than an isolated incident or was based on instructions received from corporate overlords.
The target demographic for smartphones is geekier than the average public. Most geeks have smartphones, for example. Teenagers and young adults regularly defy the traditional concept of "too geeky" or requiring too much effort for the "average" person, and these same are also among the prime candidates for smart phones.
Nonetheless, "fragmentation" is a marketing term being bandied about by Apple apologists. It's an excuse to justify a technology monoculture that Apple has established in some corners of the market. Technology monoculture has invariably led to technology stagnation.
Rather than "fragmentation" being a bad thing, what's actually going on is "innovation," and that's a good thing. People didn't talk about desktop fragmentation in the PC era, people don't talk about console fragmentation when you need specialized controllers to interact with many of today's games.
This is survival of the fittest. My wife is a complete non-geek. She traded out her iPhone for Android and is eager to ditch her iPad. The sole reason being that she wants to consume content which requires Flash. She's not interested in assertions that her life would be better if only websites would ditch Flash, she's interested that her technology can't do the task she wants it to.
Technology monoculture is the real problem here. iOS suffers from it, while Android doesn't. Android should wear this term with a badge of pride; they are currently steadfastly half way between steps 2 and 3 (out of 4) in Gandhi's famous quote about winning. They were ignored (Android 1.x era), they were laughed at ("fragmentation"), now they're being fought (Apple v. Samsung for example). Only one more step to go.
As I've observed in other comments, the iPhone 3GS running the latest version of iOS by version number isn't that impressive since the major new functionality is still locked out of the device (typically for sales reasons rather than hardware reasons such as with Siri). It's cool that you get to see a number which is the same number on newer phones, but it only grants you a carefully selected subset of the most basic of the new functionality, so it's not really the same version after all.
In contrast, on Android, if your device is at certain version, it has access to all the features from that OS version that your hardware can support (eg, you can't depend on a gyroscope if none is present).
Your chart should be updated to indicate how far back all the new major features are supported. Apple's roadmap will suddenly terminate full-feature-support for each phone line on the first SDK release after a newer phone is launched.
In the mean time, although you can still target back to iPhone 3 OS versions in XCode (letting you include people with a device that is more than two years old but excluding you from using any newer features), you can still download Android SDK's back to API level 3 (the first public api level). So you can target every commercial Android phone at once as long as you either stick within the feature set from those original devices or you're clever enough to write code that knows how to fail gracefully when a more modern feature is unavailable. For example, we do this with one of our apps which has an NFC option (first available I think in API level 10, Android 2.3.3), but has plenty of non-NFC functionality as well - targeting API level 7 (Android 2.1) and conditionally using more recent APIs if the phone's OS supports them.
So $200 for vBulletin and $150 for vBSEO per developer. Wherever you're working, get out as soon as you can, if they can't spend $350 per developer on licenses, they're going to cut a lot of other important corners - like pay raises. Seriously, that comes out to $0.16 per hour. Even if you guys are entry level guys making $16/hour, that's still just 1% premium on your pay rate to grant a substantial amount of utility (plus the conflicts involved in multiple developers working in a common environment is going to cost you more than 1% of your time).
But let's accept for the sake of argument that your company's margins are so thin that they can't support shelling out for a few licenses. Couldn't they shell out for at least a single test server that isn't production? If you want to take the cheap route, make that test server a VM image and pass a copy out to all the developers so they each have their own dedicated environment on their local machine. Refresh that image time to time with a snapshot from production and everyone even gets reasonably real data to work against.
How do you guys do source control? What do you do if two guys both have changes in the same file? What do you do if two guys are trying to work in the same file at the same time as each other (thus potentially overwriting each other's work)? I worked at a place where they had no source control and no developer-specific dev environments. We had to do a lot of shouting across the room, "Anyone working on file XYZ in folder ABC?" We'd still get files overwritten by someone else's save. Very frustrating to test when you are making changes and sometimes they're there and sometimes they're not, because someone else keeps overwriting it. Got them on source control and split environments in no time, and they couldn't believe how much that simplified their day-to-day operations.
Wow, I can't believe this is still around. It's pretty dated. Let me demonstrate:
Q3: Are compiled languages such as C safer than interpreted languages like Perl and shell scripts?
The answer is "yes", but with many qualifications and explanations.
Really? C is a safer web language than Perl? Buffer overflows and all? Their example that you might accidentally be editing a file (in production?) in Emacs and leave a backup file sitting around that someone can request, and therefore have access to its source code is so weak it's pathetic. Isn't every major modern web server already configured to refuse to serve files whose mime type it does not recognize from the file extension? "Foo.cgi~" won't be downloadable because the web server doesn't understand what a ".cgi~" file is. Never mind that this example assumes that you're engaging in the egregious sin of editing a file on a production system.
If it's not editing directly in a production system, you almost certainly have a.gitignore (or.cvsignore or.svnignore or whatever) set up to ignore backup files, so it'll never go through your build system or become part of your deployed package anyway. And STILL if you're relying on the obscurity of your source code as a security measure, you're doing something wrong. It doesn't hurt to keep the source secret, but by no means should you be compromiseable because someone was able to get a peek at one of your source files. If someone wants your source code badly enough, they just need to pay off one of your engineers and they get the entire stack source, maybe even revision history. Corporate espionage is all but impossible to track down the perpetrator unless he's very stupid, and it leaves a lot less evidence behind than traditional brute force attempts (like guessing script file names and looking for backup copies somehow left around in production).
You fail to actually address any of the technologies he mentioned as a layer above. You're talking about closing ports and other pretty standard bland basic intro-level security. Sure, there's overlap, but what he's saying is that a lot of common Internet problems are reliably and intelligently pre-solved for you if you control enough of the technology stack.
I'll pick his example of TLS since that's a good example of the sort of technology stack you can rely on in an intranet application which is prohibitive to implement in an Internet application.
If your web server has validated a TLS certificate, unless your signing authority has been compromised (and for internal purposes, that's owned by your own company's security team), you can trust the subject of the TLS cert. It is not only considered safe to assume that TLS is valid, it's widely regarded as one of the most secure possible means of authentication you can have since it includes endpoint verification on both ends. It's excellent practice, but if your CA is compromised it falls apart. Of course you're probably also relying on other proven technologies like LDAP for identification, but if someone ends up with write access to parts of LDAP they shouldn't have, this falls apart too.
In internal applications you can make these sorts of assumption that aren't really available on the public Internet since you don't control enough of the technology stack outside your own network to do so without substantial inconvenience for your customers. That doesn't make you a bad developer. In fact the opposite is likely true. If you're building an intranet web application and you think you can do a better job of managing user credentials than LDAP or a better job of securing communications than TLS, you're deluding yourself and very likely introducing security bugs into your application.
But your example pulled from the Bullshit! episode of the disabled lawyer who sued every business in a small town - even P&T recognize that this guy is a lawsuit troll. They specifically point out how he chose amounts small enough that the cost of defending against the suit is likely to exceed the cost of paying up. And they specifically point out that he was indiscriminate in whom he sent threatening letters - even showing a business which has been ADA compliant since before there was an ADA, which got the same letter as the rest of the businesses in town.
Lawsuit-happy lawyers is no more a problem with the ADA than the RIAA is a problem with the Internet. As long as there are laws, there will be people who will try to sue who have no good case. The problem is with the US legal system which doesn't do enough to protect against frivolous lawsuits. This crappy example of the "abuseability" of ADA laws is an excellent example I end up frustrated and annoyed with most Bullshit! episodes even when I strongly agree with their agenda for that episode. They do a terrible job of making their case by including this kind of non-example.
Like most P&T Bullshit! episodes, they have some valid points, and they are way off base on a lot of others. For example, complaining that drive-up ATMs have braille on them - seriously do they think that the laws should go into fantastic specifics as to exactly when each handicapped function should and should not be made available? Not only does that kind of legal complexity opens loop holes which greedy and crafty people exploit to avoid their civic responsibility, but earlier in the same episode, Penn is complaining that the ADA laws are already too complex. So which is it, are they too complex and should be simplified, or are they too simple and should be drafted in greater detail?
Also, chances are that even if there was an exception for drive-up ATMs having braille, they'd still have braille on the drive-up ATMs anyway so they didn't have to differentiate on a variety of manufacturing aspects from those ATMs on which braille makes more sense. Finally, consider a visually impaired person could be a passenger in the rear of a car, and fully capable of taking advantage of a drive-up ATM without being the driver. So it's not even like there's no way a blind person could ever use such an ATM.
WRT empty handicapped parking... Having empty handicapped parking spots is appropriate and correct. The number of spots is based on maximum capacity of the lot, have you seen otherwise 100% full lots with more than one or two empty handicapped spots? Is it really that inconvenient to walk a few more feet past an empty specialty spot if you're healthy?
Here's the thing, when the lot gets really full for you, you might have to park pretty far away, and spend 2 more minutes walking to the store. The handicapped person whose spots are all gone has to choose between going home or risking substantial injury by traversing farther than is safe, or perhaps they can't exit their vehicle at all because they needed the extra space around their vehicle for a wheelchair lift, etc. We were shopping at a large mall over this past holiday (formerly held the title of the largest mall in the world prior to Mall of America); we had to park way out in overflow parking. I only saw one empty handicapped spot, and I felt like that was too few - normal ebb and flow of people will mean that someone goes home without having gotten Christmas presents for their kids that day. At the same time I saw three cars with no visible placard parked in some of those spaces. Fortunately there was a cop present who had observed the same thing and was in the process of writing them up while we were going in. I really hope those guys got towed.
That said, I don't think this system is perfect, but the problem is not that handicapped parking capacity planning errors on the high end rather than the low end, it's that gaining access to this system is far too easy. I used to work with some folks who had gotten handicapped placards, and would boast about how they cheated the system to get them. One of them had simply had a leg injury and had been given a 'temporary' tag, which is supposedly only good for a certain amount of time. She continued using it for several years after her validity period and had yet to be caught. Plus one woman whose husband was disabled who used his placard without him present frequently as a matter of parking convenience. Basically they understood that they didn't really need this access, but they exploited how easy it is to acquire it and potentially put people legitimately in need at risk of not being able to use it.
Slashdot Mirror
It does maintain old copies of files. For 30 days, files you delete can be restored, and you can revert files to earlier versions. For a fee (an add-on called PackRat), they will keep old versions and deleted files indefinitely.
Dropbox lets you restore deleted files (or return to earlier versions of the files) for a certain amount of time. And for a fee, they keep deleted / version history indefinitely (called Pack-Rat).
If Dropbox's services are still online, you can take advantage of this. If Dropbox's services go offline, then the edits and deletes aren't synced anyway, and you still have a layer of redundancy (though you need to find a new solution for new data).
I agree that it's still not quite backup, but it is very close and completely fuss-free.
Absolutely. I have 4 dual core CPU's in my machine. When I encode video, all four are clocking at about 90-95%. Encoding an hour of video takes in the neighborhood of 10-15 minutes per pass depending on the movie, and my hardware is even a few years old, plus I'm typically decoding at the same time from a different source (eg, DVD).
Phones make a terrible book device. Bad enough that the headline on Apple's site is "The Textbook. Reinvented for iPad," not iOS. Not a single iPhone even makes an appearance on either the Textbook page or the iBooks Author page. There are plenty of iPads though.
How many iPads are out there compared to Kindles? I'd be VERY surprised if there are more $500 devices out there than $80 devices. It takes a lot more book discounts to make up for a $500 price tag than an $80 price tag too.
Sorry, "Well, if you're a REAL geek, you'd just reverse engineer the closed format" is a terrible way to excuse proprietary formats. Might as well not HAVE open formats if that's the bar for what's acceptable in the realm of openness.
It claims support for it, and it does not have problems with the ePub3 test books from http://azardi.infogridpacific.com/html/resources.html . I've looked in the new files. They're full of stuff like <object type="application/x-ibooks+shape" id="textShape-2" data-original-id="textShape-90"> and css with -ibook- prefixes.
Seriously, you've replied to me in several spots aggressively defending Apple's lock-in. Have YOU tried this in different readers? Do YOU know of a non-Apple reader which can display Apple's new book format cleanly? Maybe Apple is just really ahead of the curve in terms of formatting while maintaining compliance with the standard. But the proprietary extensions loaded in these books suggest otherwise. It's all very Microsoftish, embrace and extend.
It's all moot anyway, Apple's TOS says you can't sell a book created for iBooks through anyone but them, and only if they choose to let you (i.e. they approve of your content), and it can't cost $15 or more (that last one I actually think is not too shabby for the vast majority of cases). They can't lock you to sell only on their platform by technical means like they do with iOS apps (where you have to pretty much independently develop multiple times if you want to target multiple platforms), so they'll just produce lock-in via a licensing channel.
At least the content is accessible, I should be grateful that it's not completely locked away. Future historians will be able to access the contents of these files when Apple's licensing servers have died. Except when they're DRM encrypted, then the future is SOL.
I see ePub with a pile of proprietary extensions; it's barely an ePub at all since most of the formatting gets lost to any reader but Apple's. Almost might as well have been a .txt file, except much, much bigger.
From the terms of use:
(ii) if your Work is provided for a fee (including as part of any subscription-based product or service), you may only distribute the Work through Apple and such distribution is subject to the following limitations and conditions: (a) you will be required to enter into a separate written agreement with Apple (or an Apple affiliate or subsidiary) before any commercial distribution of your Work may take place; and (b) Apple may determine for any reason and in its sole discretion not to select your Work for distribution.
So even though it's a (horribly broken) form of ePub, it doesn't matter, you're not allowed to sell it to anyone without an iDevice, only if Apple chooses to let you, and you get to pay Apple for this privilege privilege.
No. Thanks.
It's about iPad because only iPad and iPhone can read the ibook format.
I downloaded iBooks Author and published a book to experiment with. I chose one of their templates, picking the one which seemed to have the fewest by way of zany formatting or artwork.
Although the file produced has a ".ibooks" extension, it looks like under the hood this is ePub at the heart, but with a pile of proprietary extensions on top. I renamed my published file to have an .epub extension, and loaded it up in my ebook reader. The text is readable, but the formatting is all gone. There are image assets floating around occupying space where text should be, but they were background images in the ibooks version, while here they're interfering with text flow. I'm guessing these images are responsible for the 1mb file size for a 3 page book too.
So the format may be ePub, and although the content isn't completely locked away, I might as well have published a .txt file, at least then it wouldn't be littered with garbage images. If this is an attempt to comply with existing book readers (in the spirit of the open format), it's at best a token attempt. This looks like it would be a great editor, if it was useful outside of the Apple iMpire.
Unfortunately this is a terrible time to be trying to make money off the primary education market (where government money is). Secondary education is great because kids are buying their own equipment, usually financed by their parents, and lots and lots of kids are going to college who have no business doing so. But that's typically private money, not government money.
In primary education, budgets are being cut left and right. Maybe some upper class schools will be providing iPads for their students, or private schools which require this as part of admission. But in typical public schools, the teachers and parents would revolt. You're cutting after school programs, gifted and special education, and cutting teacher heads, but you have money to buy a bunch of GADGETS?!?
iPads for primary education are terrible. They are a distraction for students; you can do too many unrelated activities on them, and are easily destroyed. If a student loses an entire bookbag full of books, the replacement costs are probably less than losing this single fragile high-theft-target device.
I don't see any mention of that on Apple's site that it's ePub. Maybe I missed it, can you give me a link that confirms this?
From what others have been saying, you can export to only one of 3 formats, their proprietary format, PDF (non-interactive, fixed page format, basically not an ebook format at all), and plain text.
It's not like we need another freaking proprietary book format. Maybe their new format has support for things existing formats don't, but books created in this software should be exportable to other open book formats such as ePub. They're not, this is just Apple trying to control a new market and claim a 43% markup on all digital book sales.
They're a bit late to this game, Amazon is pretty entrenched with Kindles already in most people's hands, and at prices which are far more approachable than iPads. It takes a lot of FREE (beer) books to make up the purchase cost of an iPad, and most books aren't free [beer].
Wrong, wrongity wrong wrong.
They tried [kodak.com] going [kodak.com] digital [kodak.com].
They were just too late.
Perhaps you missed the part where he said:
Kodak died by not getting into the digital "thing" quickly enough and then doing poorly by the time they did.
I wouldn't have pointed it out except you were so flamboyantly adamant that he missed the point he had actually opened with.
There are a handful of times where goto is simply the most elegant solution, and a handful of times where performance really matters, so encapsulating logic into a function to avoid a goto will be too costly. I've used it once since my high school BASIC days; interestingly it was only a few months ago.
We had a costly operation working against arbitrary precision numbers, with some nondeterministic aspects. Part of the data produced is very publicly visible, and because of the nondeterministic aspects of things, we had an incident where some undesirable output was produced (valid by system design, but humans found it offensive). So rather than restart the whole operation to let the nondeterministic side of things produce something more desirable, we want to change just a chunk of the data and jump back into the middle of things to recompute the downstream results.
I know I'm being vague, I have to be. I wrote the procedural equivalent, and not only did it separate tightly related logic, the performance cost was significant at this scale, even for the non-exception scenarios, and the amount of markup to support it was prohibitive. It also actually upped the CRAP score (which was already unusually high because the focus was on performance optimization). The goto alternative was literally two lines: one label and one goto, and introduced essentially no overhead for the most common use case (the vast majority of the time the produced data contains nothing offensive).
I'm still embarrassed by it, but even now going back and looking at it, I'm not sure how I would do it in a more readable or performance equivalent manner. I made sure to include a link to this comic in the source next to it, along with a clear description of why that was the path chosen over a more traditional approach.
I could be that I just fundamentally structured the flow wrong. Maybe there there was a better path through this. My team mates ribbed me for using the goto, but agreed that it was both more readable in the end, and observed the performance cost of the alternate approach; a rare exception was made in code review to allow this.
Would it make you feel better if I said "access content" instead?
My point wasn't about debating the definitions of "consume" and "content" (I specifically mentioned that I wasn't interested in debating definitions of words). My point was that she doesn't want Flash. She wants access to content which requires Flash.
It's the difference between saying, "I want to watch a movie" and "I want to use my DVD player," or the difference between "I want to go to the store" and "I want to depress the accelerator in my car." Both are technically true, but your primary desire is to watch the movie, not to manipulate the DVD player. The latter is only a means to an end, and if there's a different means to the same end (eg, Netflix, or public transit), that'd be fine. This is the same as having a tablet which runs Flash is for my wife; if she could access the same content in a different manner, she wouldn't care that it was Flash or something else.
I know this is a pretty late response, but for some reason I came back to this comment to respond. Normally I'm not that interested in being pulled into debates of nomenclature, but this one has been on my mind for a few reasons, so I figured I'd clarify.
It's just "she wants to use flash" or "she wants flash to run on her tablet" or some other simpler english, pretty please!!!!!
Actually that's not true. She doesn't care about Flash. She wants Flash on her tablet only in a round-about sense.
What she wants to do is "consume content" meaning use websites or web apps (I see some people got in a fight about what 'consume' and 'content' mean below, so I'm just clarifying since I'm not looking to get into a fight about definitions of every-day words). This content requires Flash. She doesn't want Flash, she wants the content. What she knows is that my tablet can show her this content, and her iPad can't. She's aware that the difference is Flash or not only because I told her so.
When she was looking at getting a tablet, I had warned her that the iPad can't do Flash, and she didn't really get what that meant, and didn't really care. She, like many, figured if it was important enough, there was a path to it on iDevices. She didn't count on being collateral damage in a turf war which isn't even about technology.
So I'll stick to my original statement as being closest to the truth. She wants to consume content which requires Flash. It's true that she wants Flash to run on her tablet, but this is an effect of the original statement, it's not a primary desire, the primary desire being wanting to consume that content.
Compare that to me: I want my tablet to run Flash, because I don't like someone making arbitrary decisions about what I can or cannot do with hardware I own. I actually care less about the content than she does, if I want it badly enough, I'll save it for later and look at it on my laptop or desktop. If it's not worth the effort of saving it for later, I didn't want it that badly anyway. Most of the time I don't really care that much if there's something about the content that it won't work. Most of the time when I see the Flash activation panel (I have it set to load on tap, not automatically), more often than not I just ignore it anyway.
I agree that Google as a whole is responsible for the actions of its individual branches, but it's how Google responds to the accusation that determines whether Google condones the behavior, not whether Google was able to proactively micromanage branch offices.
I don't buy your theory that because an Indian call center was involved, this automatically makes it an action blessed by corporate. Branch offices have their own budgets and discretionary spending. Maybe it was Eric Schmidt himself who told them to do this. But we really have no way of knowing, and it's a simpler explanation that one or a few employees were engaged in taking shortcuts than that Google corporate issues orders to branch offices which involve instructions to illegally misrepresent a business relationship.
Or maybe it was the Indian call center themselves who took this "initiative" and decided to lie about the relationship (that would certainly be consistent with when we fired a call center for overtly lying to our customers to shorten call times).
I'll side with Occam's Razor on this. If corporate wanted this information this badly, they'd have paid for it. The bad press and legal repercussions would outweigh the licensing costs.
Note the key words, "Google Kenya" - this is a branch office where some employee is taking a shortcut. This is hardly a condemnation of Google as a company unless and until it's demonstrated that this is either more than an isolated incident or was based on instructions received from corporate overlords.
The target demographic for smartphones is geekier than the average public. Most geeks have smartphones, for example. Teenagers and young adults regularly defy the traditional concept of "too geeky" or requiring too much effort for the "average" person, and these same are also among the prime candidates for smart phones.
Nonetheless, "fragmentation" is a marketing term being bandied about by Apple apologists. It's an excuse to justify a technology monoculture that Apple has established in some corners of the market. Technology monoculture has invariably led to technology stagnation.
Rather than "fragmentation" being a bad thing, what's actually going on is "innovation," and that's a good thing. People didn't talk about desktop fragmentation in the PC era, people don't talk about console fragmentation when you need specialized controllers to interact with many of today's games.
This is survival of the fittest. My wife is a complete non-geek. She traded out her iPhone for Android and is eager to ditch her iPad. The sole reason being that she wants to consume content which requires Flash. She's not interested in assertions that her life would be better if only websites would ditch Flash, she's interested that her technology can't do the task she wants it to.
Technology monoculture is the real problem here. iOS suffers from it, while Android doesn't. Android should wear this term with a badge of pride; they are currently steadfastly half way between steps 2 and 3 (out of 4) in Gandhi's famous quote about winning. They were ignored (Android 1.x era), they were laughed at ("fragmentation"), now they're being fought (Apple v. Samsung for example). Only one more step to go.
As I've observed in other comments, the iPhone 3GS running the latest version of iOS by version number isn't that impressive since the major new functionality is still locked out of the device (typically for sales reasons rather than hardware reasons such as with Siri). It's cool that you get to see a number which is the same number on newer phones, but it only grants you a carefully selected subset of the most basic of the new functionality, so it's not really the same version after all.
In contrast, on Android, if your device is at certain version, it has access to all the features from that OS version that your hardware can support (eg, you can't depend on a gyroscope if none is present).
Your chart should be updated to indicate how far back all the new major features are supported. Apple's roadmap will suddenly terminate full-feature-support for each phone line on the first SDK release after a newer phone is launched.
In the mean time, although you can still target back to iPhone 3 OS versions in XCode (letting you include people with a device that is more than two years old but excluding you from using any newer features), you can still download Android SDK's back to API level 3 (the first public api level). So you can target every commercial Android phone at once as long as you either stick within the feature set from those original devices or you're clever enough to write code that knows how to fail gracefully when a more modern feature is unavailable. For example, we do this with one of our apps which has an NFC option (first available I think in API level 10, Android 2.3.3), but has plenty of non-NFC functionality as well - targeting API level 7 (Android 2.1) and conditionally using more recent APIs if the phone's OS supports them.
So $200 for vBulletin and $150 for vBSEO per developer. Wherever you're working, get out as soon as you can, if they can't spend $350 per developer on licenses, they're going to cut a lot of other important corners - like pay raises. Seriously, that comes out to $0.16 per hour. Even if you guys are entry level guys making $16/hour, that's still just 1% premium on your pay rate to grant a substantial amount of utility (plus the conflicts involved in multiple developers working in a common environment is going to cost you more than 1% of your time).
But let's accept for the sake of argument that your company's margins are so thin that they can't support shelling out for a few licenses. Couldn't they shell out for at least a single test server that isn't production? If you want to take the cheap route, make that test server a VM image and pass a copy out to all the developers so they each have their own dedicated environment on their local machine. Refresh that image time to time with a snapshot from production and everyone even gets reasonably real data to work against.
How do you guys do source control? What do you do if two guys both have changes in the same file? What do you do if two guys are trying to work in the same file at the same time as each other (thus potentially overwriting each other's work)? I worked at a place where they had no source control and no developer-specific dev environments. We had to do a lot of shouting across the room, "Anyone working on file XYZ in folder ABC?" We'd still get files overwritten by someone else's save. Very frustrating to test when you are making changes and sometimes they're there and sometimes they're not, because someone else keeps overwriting it. Got them on source control and split environments in no time, and they couldn't believe how much that simplified their day-to-day operations.
Wow, I can't believe this is still around. It's pretty dated. Let me demonstrate:
Q3: Are compiled languages such as C safer than interpreted languages like Perl and shell scripts?
The answer is "yes", but with many qualifications and explanations.
Really? C is a safer web language than Perl? Buffer overflows and all? Their example that you might accidentally be editing a file (in production?) in Emacs and leave a backup file sitting around that someone can request, and therefore have access to its source code is so weak it's pathetic. Isn't every major modern web server already configured to refuse to serve files whose mime type it does not recognize from the file extension? "Foo.cgi~" won't be downloadable because the web server doesn't understand what a ".cgi~" file is. Never mind that this example assumes that you're engaging in the egregious sin of editing a file on a production system.
If it's not editing directly in a production system, you almost certainly have a .gitignore (or .cvsignore or .svnignore or whatever) set up to ignore backup files, so it'll never go through your build system or become part of your deployed package anyway. And STILL if you're relying on the obscurity of your source code as a security measure, you're doing something wrong. It doesn't hurt to keep the source secret, but by no means should you be compromiseable because someone was able to get a peek at one of your source files. If someone wants your source code badly enough, they just need to pay off one of your engineers and they get the entire stack source, maybe even revision history. Corporate espionage is all but impossible to track down the perpetrator unless he's very stupid, and it leaves a lot less evidence behind than traditional brute force attempts (like guessing script file names and looking for backup copies somehow left around in production).
You fail to actually address any of the technologies he mentioned as a layer above. You're talking about closing ports and other pretty standard bland basic intro-level security. Sure, there's overlap, but what he's saying is that a lot of common Internet problems are reliably and intelligently pre-solved for you if you control enough of the technology stack.
I'll pick his example of TLS since that's a good example of the sort of technology stack you can rely on in an intranet application which is prohibitive to implement in an Internet application.
If your web server has validated a TLS certificate, unless your signing authority has been compromised (and for internal purposes, that's owned by your own company's security team), you can trust the subject of the TLS cert. It is not only considered safe to assume that TLS is valid, it's widely regarded as one of the most secure possible means of authentication you can have since it includes endpoint verification on both ends. It's excellent practice, but if your CA is compromised it falls apart. Of course you're probably also relying on other proven technologies like LDAP for identification, but if someone ends up with write access to parts of LDAP they shouldn't have, this falls apart too.
In internal applications you can make these sorts of assumption that aren't really available on the public Internet since you don't control enough of the technology stack outside your own network to do so without substantial inconvenience for your customers. That doesn't make you a bad developer. In fact the opposite is likely true. If you're building an intranet web application and you think you can do a better job of managing user credentials than LDAP or a better job of securing communications than TLS, you're deluding yourself and very likely introducing security bugs into your application.
But your example pulled from the Bullshit! episode of the disabled lawyer who sued every business in a small town - even P&T recognize that this guy is a lawsuit troll. They specifically point out how he chose amounts small enough that the cost of defending against the suit is likely to exceed the cost of paying up. And they specifically point out that he was indiscriminate in whom he sent threatening letters - even showing a business which has been ADA compliant since before there was an ADA, which got the same letter as the rest of the businesses in town.
Lawsuit-happy lawyers is no more a problem with the ADA than the RIAA is a problem with the Internet. As long as there are laws, there will be people who will try to sue who have no good case. The problem is with the US legal system which doesn't do enough to protect against frivolous lawsuits. This crappy example of the "abuseability" of ADA laws is an excellent example I end up frustrated and annoyed with most Bullshit! episodes even when I strongly agree with their agenda for that episode. They do a terrible job of making their case by including this kind of non-example.
Like most P&T Bullshit! episodes, they have some valid points, and they are way off base on a lot of others. For example, complaining that drive-up ATMs have braille on them - seriously do they think that the laws should go into fantastic specifics as to exactly when each handicapped function should and should not be made available? Not only does that kind of legal complexity opens loop holes which greedy and crafty people exploit to avoid their civic responsibility, but earlier in the same episode, Penn is complaining that the ADA laws are already too complex. So which is it, are they too complex and should be simplified, or are they too simple and should be drafted in greater detail?
Also, chances are that even if there was an exception for drive-up ATMs having braille, they'd still have braille on the drive-up ATMs anyway so they didn't have to differentiate on a variety of manufacturing aspects from those ATMs on which braille makes more sense. Finally, consider a visually impaired person could be a passenger in the rear of a car, and fully capable of taking advantage of a drive-up ATM without being the driver. So it's not even like there's no way a blind person could ever use such an ATM.
WRT empty handicapped parking... Having empty handicapped parking spots is appropriate and correct. The number of spots is based on maximum capacity of the lot, have you seen otherwise 100% full lots with more than one or two empty handicapped spots? Is it really that inconvenient to walk a few more feet past an empty specialty spot if you're healthy?
Here's the thing, when the lot gets really full for you, you might have to park pretty far away, and spend 2 more minutes walking to the store. The handicapped person whose spots are all gone has to choose between going home or risking substantial injury by traversing farther than is safe, or perhaps they can't exit their vehicle at all because they needed the extra space around their vehicle for a wheelchair lift, etc. We were shopping at a large mall over this past holiday (formerly held the title of the largest mall in the world prior to Mall of America); we had to park way out in overflow parking. I only saw one empty handicapped spot, and I felt like that was too few - normal ebb and flow of people will mean that someone goes home without having gotten Christmas presents for their kids that day. At the same time I saw three cars with no visible placard parked in some of those spaces. Fortunately there was a cop present who had observed the same thing and was in the process of writing them up while we were going in. I really hope those guys got towed.
That said, I don't think this system is perfect, but the problem is not that handicapped parking capacity planning errors on the high end rather than the low end, it's that gaining access to this system is far too easy. I used to work with some folks who had gotten handicapped placards, and would boast about how they cheated the system to get them. One of them had simply had a leg injury and had been given a 'temporary' tag, which is supposedly only good for a certain amount of time. She continued using it for several years after her validity period and had yet to be caught. Plus one woman whose husband was disabled who used his placard without him present frequently as a matter of parking convenience. Basically they understood that they didn't really need this access, but they exploited how easy it is to acquire it and potentially put people legitimately in need at risk of not being able to use it.