Drone:
- Can fly out of line of sight.
- Transmits video in real time.
- Can accept high level commands, such as position and heading, and handles pitch/roll/yaw itself.
- You control it by looking at the video.
Check out the Hubsan H107D FPV X4. It's in a bit a grey area regarding your definitions. It can fly out of line of sight and transmits video in real time, and it's only about $150. It doesn't have GPS and can not be programmed, so it fails the full-out drone spec. I'd still call it an RC toy, but if you've got FPV video it's still a great stepping stone to spending buttloads on something high-end!
Now backup that dataset weekly for two months, tape wins easily. Even without the need for archives a minimal useful backup strategy favors tape.
This can be done if plan it correctly for the medium of choice. If you're doing full snapshot backups weekly, you're rigging the game for tape to win.
Just one example that can work and achieve similar or greater levels data integrity and more fine grained backups (ex. daily):
* BackupPC server * two external raid arrays (cheap-ish USB or ESATA things with JBOD and software raid) * take one offsite * do backups on the other * swap periodically (weekly, per your requirement)
It'll use far less storage space due to file level dedupe and compression, so you don't actually need the same amount of raw storage space. Availability is faster, especially for random file restores. You can do far more frequent backups. Total cost will be less.
Granted, while they're both backups, they have some fundamental differences. BackupPC, for example, is not suited to doing bare metal restores. That's not it's purpose though, and what it does do, it does very well (as do similar commercial products).
Tape wins easily given specific requirements that favor it, and those requirements may be justified. However, for a very large amount of backup needs, even in the enterprise, disk can win in many ways. There are really way to many factors to just say one is best, and there's a lot of middle ground where a blend of the two is better, or either-or may be fine. When you add in the cloud (ex. Amazon Glacier), it makes it really easy to consider dropping tape from the mix.
It's 2014, you can just run your backups to low cost cloud storage that is replicated across the world.
And when an array dies and you need to load all 5 TB of data from backup, let us know what your boss says when you tell him it'll take a week to restore, assuming a 100Mbit internet connection.
1. he included keeping a local copy, so unless both the production RAID and the local backup system both failed, he'd just pull it from the local copy.
2. It won't take a week if you're using the right cloud thingy. Ex. Amazon Glacier has an Import/Export and they can ship around drives with your data: http://aws.amazon.com/importex... They also have a Direct Connect option, so you could establish a high speed dedicated network connection from you to them, bypassing the internet at large, going up to 10 Gbps.
FWIW, I wouldn't rely on it as the only backup storage. However, based on your statement, I'm assuming you're restoring from local media as well, so all is equal there (he said he'd have a local copy). How well does your offsite deal with restores?
Disclaimer: I've yet to use Glacier. I just really like the design, pricing, and features, and I want to use it at some point. For my personal data, it's a non-starter because I have insufficient upstream bandwidth (sneaker net FTW, ugh). For work, we already have a bunch of data centers with fat dedicated pipes between them (I'm still hoping to move to Glacier to greatly reduce (not eliminate) the crap we have to maintain).
I don't think a law will be needed, but IMO you are exactly right that cross compatibility will be key.
Personally, I'm hoping that HTML5/AJAX/etc gets to be such a big deal that all data going to/from facebook is done that way. It's then a fairly clean API others can use (even if there are legal issues with that). It could be done now with a mix of that and screen scraping, but it'd be difficult to keep up.
If, at some point, someone created a client based application (probably browser based and in javascript) that had a plugin for facebook, and turned those streams into a common format (pick one of the better open source distributed/federated social networks and use that format), then it could offer federation to facebook to said distributed network.
One thing I'm curious about, but not enough to research right now, is the compatibility of the existing federated social networks! I'm kind of amazed that wasn't the whole point of the main article. If they're federated, can they talk to each other? If not, why not? I don't care if they don't share internal API's, but the first thing they should make (during or after working out their internals) is a way to talk to each other in a common way. Do that, and all the ones listed on the main article (and more) become one big network - still probably not enough to sway a significant part of facebook users, but that doesn't really matter. This has to come first. Then add a plugin (possibly unofficial due to legal reasons) to plug in facebook.
Maybe/hopefully, facebook will take up that charge. They won't gain those external users, but they'd be giving their users access to the other networks where some small group of more security/privacy/just-plain-paranoid people reside.
I like to think of it somewhat like email. "You got mail"... AOL is more-or-less dead, but not because they allowed users to interact via email with external networks. That may be the only thing that kept them alive as long as it has. Of course, email was designed from the ground up to work that way, so we'll have to work backwards.
This post is getting too long, but one last thing... I'm really disappointed in Google Hangouts. They had talk, and it was federated, and anyone with an XMPP/Jabber server could federate with them, but they're cutting that off. This is not just a disappointment with Google, but with all these types of networks. IM is SOOOO much easier than social, and yet MSN, AIM, Jabber/XMPP, Google Hangouts, Yahoo, MS Lync... they can't talk to each other**. That's just stupid. The Google move is a step backward, and does not bode well for integration of social networks.
** I know there are ways to do this, such as with XMPP bridges, but they're ugly and generally unsupported. AFAIK, I can't search for an MSN user while on AIM, and in this day and age, that's stupid.
You could fit every tool with an RFID tag and put a small computer with an RFID reader in the tool box....
This was one of the best ideas I ever saw when I read it in one of Cory Doctorow's books. I think the book was "Makers", and here's the excerpt where it was introduced: http://www.iconeye.com/404/ite...
Job security has its own value, along with enjoyment. You can't base everything off of the pay.
Job security is a myth. You're only chance at job security in a large company is to do what the GP stated, "so they can hide in a corner doing minimal work while collecting a mediocre salary".
Those tireless technical people will actually have better job security at a start up or small shop. They often need a lot of things that large companies frown upon, like flexible hours (to support binge sessions of 18hr days busting out some new thing), some level of control/authority over design and business decisions that would otherwise get delayed with red tape (ex. purchasing several additional servers to support some new thing/design/etc; if it's delayed, it'll ruin their momentum), lower overhead of stupid rules and meetings and such allowing them to focus, etc. These *can* be had at a larger company, but its rare, and it's not often tolerated.
I can't speak for the GP, but I doubt he was basing everything off of pay. That sounds like one of the least important factors, but it doesn't hurt the decision.
Why is a pay check important? Having a portfolio of work, be it class projects, contributions to an open source project, perhaps having a patent granted, etc. should count just as much as earning a pay check for a few years working as an assistant code monkey to the junior developer of some corporate sub-project.
While I agree with the other replies to your comment (ie. it is quite different and very important), none of them seem to mention the grey area here where you are right. That is, having a portfolio of unpaid work can be plenty in order to get a low to mid level developer job.
However, the question was about a lead developer position. At that level, you can disregard the "developer" part in order to answer this question as it applies to practically all professions. It doesn't matter how awesome you are at the core task (translating ideas into code that works) if you have zero experience with all the other duties that make up a head/chief/lead position.
This also goes the other direction. An applicant could have years of experience being a very effective manager in another field but, if they do not have any development experience, they shouldn't get the lead developer position. The position bridges two areas of expertise and requires experience in both.
The dual role has one relaxed restriction - you do not need to be the hottest code monkey there is, nor do you need to be a six sigma black belt. You do need to understand both and how to communicate across the domains.
but they weren't clearly criminal things either (letter of the law, maybe, but it's not like he was knowingly training terrorists or killing people etc)
Umm, did you read the indictment? One of his would be clients told him that he was worried about his polygraph because he had engaged in smuggling while employed for Homeland Security. He proceeded to assist that would be client (actually an Undercover LEO) with the falsification of his testimony to the Federal Government. Mens rea was clearly evident on the part of Mr. Williams.
Assuming that's all true, yeah, those things are illegal. IMO, and I realize this doesn't follow all the laws on the books, is that the main thing he was doing is not illegal at all. The polygraph is not accurate, and he shows people how it works (or doesn't work). Who cares why someone wants to beat one if they aren't admissible anyway? Yes, technically he should have stopped the guy before he knew the motivation or aborted once he knew it, but that extra fluff really shouldn't matter. He's getting strung up on technicalities.
If they busted a drug mule with a ton of coke, but only got him for speeding, lying to an officer, and transporting goods across a state line without the right documentation, I'd say the same thing... the stuff they're busing him for aren't all that awful. Difference is, in this case the actual thing he was doing was perfectly fine, thus all the, "suppress speech that the U.S. government dislikes," type of reactions.
Greed? it was just $5k. Federal crimes? they're some of the weakest/generic white-collar ones that exist. It's Martha Stewart level bullshit. Technically illegal, and he'll almost certainly go to prison for it, but these aren't the sort of things that directly threatening to society.
Here's a question for you (or anyone): do you think he is horrible and evil, or do you think he just made some stupid mistakes?
I didn't realise there was so much money involved. Looks like Scam VS Scam.
I didn't read the article. Are you referring to the same figure Shakrai quoted - $5000?
Sorry, but that's NOT a lot of money. If he had one $5k client a month, that's only $50k/year. Sure, he *could* have more clients, but I doubt the demand is all that high, and I suspect that the training takes a fair bit of time, even if it is very simple in theory. It's not like he's got a bunch of employees and is making millions.
As far as greed goes, this is more like greed to have enough money to live on, not greed to have piles of surplus cash.
He made a couple statements/choices that could (and did) get him in trouble, but they weren't clearly criminal things either (letter of the law, maybe, but it's not like he was knowingly training terrorists or killing people etc).
The encryption is a method I use to keep others from reading said copyrited work, correct?
Nope. In this case, the work is not itself encrypted, the communication channel to but one mail server is. Apply GPG, GPG, or S/MIME encryption and your message body is still safe.
In addition, they're goal was 35,000 €. In comparison to commercial development, that's damn near free.
You can continue to: * pay zero and use nothing * use any of the existing free-ish editors that don't have the features this has * pay zero and pirate some commercial software * pay your monthly subscription for creative cloud etc * pay ~$1k for a license to something like Final Cut Pro or Premier Pro * pay nothing and still end up using this after others put their time and money into it and still complain because they asked for money
Why *wouldn't* you donate money to an open source project?
So you still have to buy an iPhone, an iPad, an Android phone, and an Android tablet to test on them...
1. If you're doing any serious development, you should have this already 2. If your'e not very serious, then the andriod or ipad you personally use will be fine. For iPhone/iPad/etc testing, there is already a requirement to have something running Mac OSX + it's dev tools, or to own an i*thing* = no change here.
... and an essential Linux component has to be built from source.
Oh no! They're expecting developers (the target audience) to *gasp* build something from source!!!
Come on, there has to be more legitimate things to complain about!
Or more than two years ago: http://science.slashdot.org/su...... and this link is for a story that is also from "Researches from North Carolina State University".
The lack of a usability-by-ordinary-people rating was sad. That's the main reason I went to look at the page, and I see no rating regarding that at all. Some of those are much more usable than others. Would be really nice to include that info, but I guess that gets more subjective (which is why I wanted to read it anyway). It's still a nice (though small) start.
Fedora was the first distro to go systemd by default back in F15. There were a few growing pains, but there wasn't the coordinated systemd hatred until pretty much recently when RHEL7 went out the door and debian said we're going systemd.
I don't know why this would be amusing or surprising. Any distro could adopt any new feature/system/etc and, while there may be criticism, the majority will not be up in arms regardless of the decision is there are still a wide variety of other acceptable distros that retain the previous feature.
For example, if RHEL (and thus CentOS), and Suse, and Fedora, and Ubuntu, and Debian all went to Gnome 3 at the same time and did so with tight integration (ie. not simple to downgrade to Gnome 2), then everyone would be up in arms. However, if the change is staggered across different distros, and others using those have time to make well supported forks (e. Cinnamon and MATE based distros like Mint), then the backlash is kept to a minimum. IE. people will still complain, but it's useless complaining because they can easily move to Mint MATE and continue to enjoy a Unbutu-based experience with Gnome 2.
Systemd's widespread adoption by distros is, contrary to what many may think, causing a lot of the issues. Lots of people tend to think that, if only development/management/maintenance/etc effort were not spread across these different competing projects, then so much more advancement would be made in Linux. IMO, that is a very misguided philosophy. Competition in OSS projects allows each to try things they would otherwise not try if EVERYONE used it, thus allowing significant advancements to be made; and due to similar licenses and/or devs etc, features can be cherry picked and brought to all as they are proven.
A rough example: I used ESD (enlightenment sound daemon) with OSS (Open Sound System) when ESD first came out. I later used ARTS (analog real time synthesizer) instead of ESD, then replaced OSS with ALSA (Advanced Linux Sound Architecture) and went back to ESD, and also used straight up ALSA for a while. Pulse made a lot of that flexibility more difficult. It was still possible to replace pulse, and many people did, but it wasn't as easy as swapping ESD and ARTS or OSS and ALSA (not to mention the many other similar projects like NAS and MPD).
Another example: I used to use whatever window manager with my desktop environment that I wanted. It was all very mix-and-match, as was moving between straight startx and XDM/GDM/KDM. That's all changed quite a bit. Much of that can still be done, but it's no longer clear and obvious and trivial (AFAICT). However, we don't see Unity+Mir being pushed out as the default on all distros. Some people using ubuntu may groan, but they can use any other flavor of ubuntu they like (kubuntu, xubuntu, lubuntu, or a fork like mint + their wide selection of DM's).
One of the issues with systemd is that, if you don't want to use it for whatever reason, where do you turn? What if one doesn't want to use systemd for init, but still wants logind and/or systemd-dbus? or just systemd-syslog? or wants systemd for init but doesn't want it for syslog/cron/dbus/etc? (uselessd may answer the latter, but I don't know of any distros using it yet). This may all be answered in time, but the wide adoption, broad feature list, tight bindings, and relative immaturity (as in age of the project) make this difficult to accept. More people involved all at once = more grumbling.
The article is completely wrong. The current version of Hypercard (RunRev's LiveCode) is cross platform: iOS, Android, BlackBerry, Windows Phone, Windows Desktop, Linux Desktop, Mac.
And there are plenty of clones, many even supporting the original stacks. Google came back with this pretty quickly: http://hypercard.org/ livecode looks fairly well polished though, and it's free-as-in-beer at least, so the only "revival" that's needed is marketing - assuming there's a market.
Here's an idea. Rather than bicker about this point (parallel startup with dependency resolution versus manually ordered one at a time startup), could some nice systemd dev add support for (or show an example of how to do) startup the old way using systemd?
Given that systemd has (presumably) good dependency resolution, it should be not only possible but somewhat easy to define start up job dependencies such that they run one at a time in order. For example, add a bunch of units (or whatever they're called) that are just 001 - 999 and each depend on the former (so 999 depends on 998, 998 on 997,... 002 on 001). Then, for each actual unit that does stuff, give it one dependency of the numbered startup where you want it to run (ex. sysstat depends on 001, lvs2-monitor on 002, iptables on 008, network on 010, etc).
There's probably a better/easier way to do that, but I imagine something like that would work. Having this option/example would take care of at least this concern from systemd adoption.
As a side note, this comment of yours is BS:
if understanding the dependencies is too hard for you, don't re-order them. You should not need to, it is not a normal part of system administration or software development.
If I write some daemon, I'm going to have to get it started with the system (and yes, I've written several, and it used to not be uncommon for users to do this). Under traditional sysvinit systems, something like a simple symlink to the right/etc/rc3.d/SNNservicename and I know exactly when it'll start. Yes, one could figure out the dependency tree and put it in the right place in systemd. While that's probably not all that difficult, it's certainly more difficult than "ls -1/etc/rc3.d" and looking at the sort order.
How do prepared statements handle the not uncommon situation where you want to include an "in" clause? For example:
select * from customers where city in ?citylist
This was the problem they tried to solve by dynamically creating a statement like:
select * from customers where city in (?city-1, ?city-2, ?city-3)
So, to generate the -1, -2, and -3 parts they relied upon the index of the array.
...
for which there are no good solutions with plain prepared statements.
...
Bullshit. Psuedo code cause I'm too lazy to look up the php-ism for this: $stmt = "select * from customers where city in (".join(',', map { '?' } array_values($city_list) ).")"; $sth = $db->prepare($stmt); $sth->ececute(array_values($city_list));
Wrapper code to aid in building the placeholder stuff should be used to account for max count of items (generally 255 of them), after which it should split it to: ( city in (?,?,?... etc...) OR city in (?,?,?... etc...) )
Does that take work? yes. Is it more effort than what they're doing? no.
... roll-your-own implementations are likely to be broken too.
As far as I can tell, this module uses custom placeholders in queries, and then replaces those with the user supplied values, building a string that can be passed to the DB as SQL without database placeholders. IE. it's not building something like:
$db->prepare("SELECT name FROM table WHERE something IN (?,?,?)")
$db->execute( @parameters );
It's building something like:
$db->prepare("SELECT name FROM table WHERE something IN ($param[0], $param[1], $param[2])")
That's always more risky. DB placeholders are not a silver bullet, but they're damn close./disclaimer, I didn't thoroughly audit the code, so maybe it is somehow using db placeholders, but the method in question doesn't look like it is. See line 739 here: http://cgit.drupalcode.org/dru... Patch for users that don't want to do a full upgrade and are on 7.0 - 7.31: https://www.drupal.org/files/i...
Except that most users' connection won't be able to upload even close to 3 TB in a day.
Correct, and even the fastest aren't going to do it. On an OC3 (156 Mbps) 3TB would take over 46 hours (almost 4 days). On an OC12 (622 Mbps), it's about 11.5 hours. FiOS 50/50 plan is over 6 days.
I don't know what FiOS fastest is (maybe 150/150, since someone above mentioned it), but that's still 4 days. How many people have a dedicated OC12 at home?
But storage on the intranet remains miniscule and expensive. Try to get a partition big enough to build a reasonably sized virtual instance, and you'll get handed 20 Gbytes because "storage is expensive".
And so, potential customers continue to do their stuff on their own PC, because really, storage isn't that expensive.
[bold by me] Is that really what you mean? Do you mean that when you ask your local IT for space, you get jack squat? IMO, that's their own (bad) decisions. They can easily do the same sort of thing the others are doing to provide loads of space. There's lots of ways to do it, but here's a really simple one: use a bunch of white box servers; max out their onboard SATA with largest disks you can get; stick glusterfs on them all and enable sufficient redundancy. In most cases, they'll probably still go with the vendor suggested enterprise storage and will pay through the nose for it and disks - it's sad, but it runs and then can blame someone else if there's a problem.
Or do you mean virtual servers (like linode, though they and most others have moved to 100% SSD)? They do keep upping the space, but you'd be right here.
rsync.net is swell, but the price is crazy. For example, $140/month for 1 TB. I had to re-read it several times to make sure I wasn't misreading it. For comparison, Dropbox is $9.99/month for 1 TB. Granted, rsync.net has a very different feature set that is very flexible. However, I wish I could pay 1/10th the cost and manage the redundancy and number of snapshots and such myself (ie. a purpose built vm with a big data drive).
Even then, circumstances can alter the situation, since if you create a bunch of *huge* tablespaces on a virgin FS and they never extend, then you can get up to a high usage percentage without fragmentation.
This. To explain it to uses that have no clue what a tablespace is, but may know what a partition is, imagine:
* setting up a separate partition for every set of similar sized files * for very large files, give each its own partition * pad every file in out to a fixed size
For example, for mp3's, pad every one of them to 6mb (I'm guessing; do some stats on your archive to determine optimal size). Every time you write one, it's 6mb to that one partition. If you delete one, there will be a hole in the filesystem, but it will be exactly 6mb. Next time you write one, it will fill in the hole = no significant fragmentation.
In that case, you can allocate 100% of the drive. Planning for growth is left up to you, and the above isn't really a perfect description of tablespaces:-)
Back to the typical desktop, AFAIK, the 10% rule still applies. It's not for growth, it's for optimal filesystem performance. Less than that an there's not enough free space to avoid significant fragmentation under typical usage. If you consider the above, it may be obvious that some files are worse than others at contributing to fragmentation. Log files, for example, can be awful. FS's do a damn good job nonetheless.
Slashdot Mirror
Drone:
- Can fly out of line of sight.
- Transmits video in real time.
- Can accept high level commands, such as position and heading, and handles pitch/roll/yaw itself.
- You control it by looking at the video.
Check out the Hubsan H107D FPV X4. It's in a bit a grey area regarding your definitions. It can fly out of line of sight and transmits video in real time, and it's only about $150. It doesn't have GPS and can not be programmed, so it fails the full-out drone spec. I'd still call it an RC toy, but if you've got FPV video it's still a great stepping stone to spending buttloads on something high-end!
Now backup that dataset weekly for two months, tape wins easily. Even without the need for archives a minimal useful backup strategy favors tape.
This can be done if plan it correctly for the medium of choice. If you're doing full snapshot backups weekly, you're rigging the game for tape to win.
Just one example that can work and achieve similar or greater levels data integrity and more fine grained backups (ex. daily):
* BackupPC server
* two external raid arrays (cheap-ish USB or ESATA things with JBOD and software raid)
* take one offsite
* do backups on the other
* swap periodically (weekly, per your requirement)
It'll use far less storage space due to file level dedupe and compression, so you don't actually need the same amount of raw storage space.
Availability is faster, especially for random file restores.
You can do far more frequent backups.
Total cost will be less.
Granted, while they're both backups, they have some fundamental differences. BackupPC, for example, is not suited to doing bare metal restores. That's not it's purpose though, and what it does do, it does very well (as do similar commercial products).
Tape wins easily given specific requirements that favor it, and those requirements may be justified. However, for a very large amount of backup needs, even in the enterprise, disk can win in many ways. There are really way to many factors to just say one is best, and there's a lot of middle ground where a blend of the two is better, or either-or may be fine. When you add in the cloud (ex. Amazon Glacier), it makes it really easy to consider dropping tape from the mix.
It's 2014, you can just run your backups to low cost cloud storage that is replicated across the world.
And when an array dies and you need to load all 5 TB of data from backup, let us know what your boss says when you tell him it'll take a week to restore, assuming a 100Mbit internet connection.
1. he included keeping a local copy, so unless both the production RAID and the local backup system both failed, he'd just pull it from the local copy.
2. It won't take a week if you're using the right cloud thingy. Ex. Amazon Glacier has an Import/Export and they can ship around drives with your data: http://aws.amazon.com/importex...
They also have a Direct Connect option, so you could establish a high speed dedicated network connection from you to them, bypassing the internet at large, going up to 10 Gbps.
FWIW, I wouldn't rely on it as the only backup storage. However, based on your statement, I'm assuming you're restoring from local media as well, so all is equal there (he said he'd have a local copy). How well does your offsite deal with restores?
Disclaimer: I've yet to use Glacier. I just really like the design, pricing, and features, and I want to use it at some point. For my personal data, it's a non-starter because I have insufficient upstream bandwidth (sneaker net FTW, ugh). For work, we already have a bunch of data centers with fat dedicated pipes between them (I'm still hoping to move to Glacier to greatly reduce (not eliminate) the crap we have to maintain).
I don't think a law will be needed, but IMO you are exactly right that cross compatibility will be key.
Personally, I'm hoping that HTML5/AJAX/etc gets to be such a big deal that all data going to/from facebook is done that way. It's then a fairly clean API others can use (even if there are legal issues with that). It could be done now with a mix of that and screen scraping, but it'd be difficult to keep up.
If, at some point, someone created a client based application (probably browser based and in javascript) that had a plugin for facebook, and turned those streams into a common format (pick one of the better open source distributed/federated social networks and use that format), then it could offer federation to facebook to said distributed network.
One thing I'm curious about, but not enough to research right now, is the compatibility of the existing federated social networks! I'm kind of amazed that wasn't the whole point of the main article. If they're federated, can they talk to each other? If not, why not? I don't care if they don't share internal API's, but the first thing they should make (during or after working out their internals) is a way to talk to each other in a common way. Do that, and all the ones listed on the main article (and more) become one big network - still probably not enough to sway a significant part of facebook users, but that doesn't really matter. This has to come first. Then add a plugin (possibly unofficial due to legal reasons) to plug in facebook.
Maybe/hopefully, facebook will take up that charge. They won't gain those external users, but they'd be giving their users access to the other networks where some small group of more security/privacy/just-plain-paranoid people reside.
I like to think of it somewhat like email. "You got mail"... AOL is more-or-less dead, but not because they allowed users to interact via email with external networks. That may be the only thing that kept them alive as long as it has. Of course, email was designed from the ground up to work that way, so we'll have to work backwards.
This post is getting too long, but one last thing... I'm really disappointed in Google Hangouts. They had talk, and it was federated, and anyone with an XMPP/Jabber server could federate with them, but they're cutting that off. This is not just a disappointment with Google, but with all these types of networks. IM is SOOOO much easier than social, and yet MSN, AIM, Jabber/XMPP, Google Hangouts, Yahoo, MS Lync... they can't talk to each other**. That's just stupid. The Google move is a step backward, and does not bode well for integration of social networks.
** I know there are ways to do this, such as with XMPP bridges, but they're ugly and generally unsupported. AFAIK, I can't search for an MSN user while on AIM, and in this day and age, that's stupid.
You could fit every tool with an RFID tag and put a small computer with an RFID reader in the tool box. ...
This was one of the best ideas I ever saw when I read it in one of Cory Doctorow's books. I think the book was "Makers", and here's the excerpt where it was introduced: http://www.iconeye.com/404/ite...
Job security has its own value, along with enjoyment. You can't base everything off of the pay.
Job security is a myth.
You're only chance at job security in a large company is to do what the GP stated, "so they can hide in a corner doing minimal work while collecting a mediocre salary".
Those tireless technical people will actually have better job security at a start up or small shop. They often need a lot of things that large companies frown upon, like flexible hours (to support binge sessions of 18hr days busting out some new thing), some level of control/authority over design and business decisions that would otherwise get delayed with red tape (ex. purchasing several additional servers to support some new thing/design/etc; if it's delayed, it'll ruin their momentum), lower overhead of stupid rules and meetings and such allowing them to focus, etc. These *can* be had at a larger company, but its rare, and it's not often tolerated.
I can't speak for the GP, but I doubt he was basing everything off of pay. That sounds like one of the least important factors, but it doesn't hurt the decision.
Why is a pay check important? Having a portfolio of work, be it class projects, contributions to an open source project, perhaps having a patent granted, etc. should count just as much as earning a pay check for a few years working as an assistant code monkey to the junior developer of some corporate sub-project.
While I agree with the other replies to your comment (ie. it is quite different and very important), none of them seem to mention the grey area here where you are right. That is, having a portfolio of unpaid work can be plenty in order to get a low to mid level developer job.
However, the question was about a lead developer position. At that level, you can disregard the "developer" part in order to answer this question as it applies to practically all professions. It doesn't matter how awesome you are at the core task (translating ideas into code that works) if you have zero experience with all the other duties that make up a head/chief/lead position.
This also goes the other direction. An applicant could have years of experience being a very effective manager in another field but, if they do not have any development experience, they shouldn't get the lead developer position. The position bridges two areas of expertise and requires experience in both.
The dual role has one relaxed restriction - you do not need to be the hottest code monkey there is, nor do you need to be a six sigma black belt. You do need to understand both and how to communicate across the domains.
but they weren't clearly criminal things either (letter of the law, maybe, but it's not like he was knowingly training terrorists or killing people etc)
Umm, did you read the indictment? One of his would be clients told him that he was worried about his polygraph because he had engaged in smuggling while employed for Homeland Security. He proceeded to assist that would be client (actually an Undercover LEO) with the falsification of his testimony to the Federal Government. Mens rea was clearly evident on the part of Mr. Williams.
Assuming that's all true, yeah, those things are illegal. IMO, and I realize this doesn't follow all the laws on the books, is that the main thing he was doing is not illegal at all. The polygraph is not accurate, and he shows people how it works (or doesn't work). Who cares why someone wants to beat one if they aren't admissible anyway? Yes, technically he should have stopped the guy before he knew the motivation or aborted once he knew it, but that extra fluff really shouldn't matter. He's getting strung up on technicalities.
If they busted a drug mule with a ton of coke, but only got him for speeding, lying to an officer, and transporting goods across a state line without the right documentation, I'd say the same thing... the stuff they're busing him for aren't all that awful. Difference is, in this case the actual thing he was doing was perfectly fine, thus all the, "suppress speech that the U.S. government dislikes," type of reactions.
Greed? it was just $5k.
Federal crimes? they're some of the weakest/generic white-collar ones that exist. It's Martha Stewart level bullshit. Technically illegal, and he'll almost certainly go to prison for it, but these aren't the sort of things that directly threatening to society.
Here's a question for you (or anyone): do you think he is horrible and evil, or do you think he just made some stupid mistakes?
I didn't realise there was so much money involved.
Looks like Scam VS Scam.
I didn't read the article. Are you referring to the same figure Shakrai quoted - $5000?
Sorry, but that's NOT a lot of money. If he had one $5k client a month, that's only $50k/year. Sure, he *could* have more clients, but I doubt the demand is all that high, and I suspect that the training takes a fair bit of time, even if it is very simple in theory. It's not like he's got a bunch of employees and is making millions.
As far as greed goes, this is more like greed to have enough money to live on, not greed to have piles of surplus cash.
He made a couple statements/choices that could (and did) get him in trouble, but they weren't clearly criminal things either (letter of the law, maybe, but it's not like he was knowingly training terrorists or killing people etc).
The encryption is a method I use to keep others from reading said copyrited work, correct?
Nope. In this case, the work is not itself encrypted, the communication channel to but one mail server is.
Apply GPG, GPG, or S/MIME encryption and your message body is still safe.
Agreed with AC.
In addition, they're goal was 35,000 €. In comparison to commercial development, that's damn near free.
You can continue to:
* pay zero and use nothing
* use any of the existing free-ish editors that don't have the features this has
* pay zero and pirate some commercial software
* pay your monthly subscription for creative cloud etc
* pay ~$1k for a license to something like Final Cut Pro or Premier Pro
* pay nothing and still end up using this after others put their time and money into it and still complain because they asked for money
Why *wouldn't* you donate money to an open source project?
So you still have to buy an iPhone, an iPad, an Android phone, and an Android tablet to test on them...
1. If you're doing any serious development, you should have this already
2. If your'e not very serious, then the andriod or ipad you personally use will be fine. For iPhone/iPad/etc testing, there is already a requirement to have something running Mac OSX + it's dev tools, or to own an i*thing* = no change here.
... and an essential Linux component has to be built from source.
Oh no! They're expecting developers (the target audience) to *gasp* build something from source!!!
Come on, there has to be more legitimate things to complain about!
From almost exactly a year ago...
http://science.slashdot.org/st...
Or more than two years ago: http://science.slashdot.org/su... ... and this link is for a story that is also from "Researches from North Carolina State University".
The lack of a usability-by-ordinary-people rating was sad. That's the main reason I went to look at the page, and I see no rating regarding that at all.
Some of those are much more usable than others. Would be really nice to include that info, but I guess that gets more subjective (which is why I wanted to read it anyway).
It's still a nice (though small) start.
What if one doesn't want to use systemd for init, but still wants logind and/or systemd-dbus?
You don't. Just like you can't use XRender without an X11 implementation.
So you can, since you could use XFree86 or Xorg or Kdrive and probably others.
Fedora was the first distro to go systemd by default back in F15. There were a few growing pains, but there wasn't the coordinated systemd hatred until pretty much recently when RHEL7 went out the door and debian said we're going systemd.
I don't know why this would be amusing or surprising. Any distro could adopt any new feature/system/etc and, while there may be criticism, the majority will not be up in arms regardless of the decision is there are still a wide variety of other acceptable distros that retain the previous feature.
For example, if RHEL (and thus CentOS), and Suse, and Fedora, and Ubuntu, and Debian all went to Gnome 3 at the same time and did so with tight integration (ie. not simple to downgrade to Gnome 2), then everyone would be up in arms. However, if the change is staggered across different distros, and others using those have time to make well supported forks (e. Cinnamon and MATE based distros like Mint), then the backlash is kept to a minimum. IE. people will still complain, but it's useless complaining because they can easily move to Mint MATE and continue to enjoy a Unbutu-based experience with Gnome 2.
Systemd's widespread adoption by distros is, contrary to what many may think, causing a lot of the issues. Lots of people tend to think that, if only development/management/maintenance/etc effort were not spread across these different competing projects, then so much more advancement would be made in Linux. IMO, that is a very misguided philosophy. Competition in OSS projects allows each to try things they would otherwise not try if EVERYONE used it, thus allowing significant advancements to be made; and due to similar licenses and/or devs etc, features can be cherry picked and brought to all as they are proven.
A rough example: I used ESD (enlightenment sound daemon) with OSS (Open Sound System) when ESD first came out. I later used ARTS (analog real time synthesizer) instead of ESD, then replaced OSS with ALSA (Advanced Linux Sound Architecture) and went back to ESD, and also used straight up ALSA for a while. Pulse made a lot of that flexibility more difficult. It was still possible to replace pulse, and many people did, but it wasn't as easy as swapping ESD and ARTS or OSS and ALSA (not to mention the many other similar projects like NAS and MPD).
Another example: I used to use whatever window manager with my desktop environment that I wanted. It was all very mix-and-match, as was moving between straight startx and XDM/GDM/KDM. That's all changed quite a bit. Much of that can still be done, but it's no longer clear and obvious and trivial (AFAICT). However, we don't see Unity+Mir being pushed out as the default on all distros. Some people using ubuntu may groan, but they can use any other flavor of ubuntu they like (kubuntu, xubuntu, lubuntu, or a fork like mint + their wide selection of DM's).
One of the issues with systemd is that, if you don't want to use it for whatever reason, where do you turn? What if one doesn't want to use systemd for init, but still wants logind and/or systemd-dbus? or just systemd-syslog? or wants systemd for init but doesn't want it for syslog/cron/dbus/etc? (uselessd may answer the latter, but I don't know of any distros using it yet). This may all be answered in time, but the wide adoption, broad feature list, tight bindings, and relative immaturity (as in age of the project) make this difficult to accept. More people involved all at once = more grumbling.
The article is completely wrong. The current version of Hypercard (RunRev's LiveCode) is cross platform: iOS, Android, BlackBerry, Windows Phone, Windows Desktop, Linux Desktop, Mac.
And there are plenty of clones, many even supporting the original stacks. Google came back with this pretty quickly: http://hypercard.org/
livecode looks fairly well polished though, and it's free-as-in-beer at least, so the only "revival" that's needed is marketing - assuming there's a market.
Here's an idea. Rather than bicker about this point (parallel startup with dependency resolution versus manually ordered one at a time startup), could some nice systemd dev add support for (or show an example of how to do) startup the old way using systemd?
Given that systemd has (presumably) good dependency resolution, it should be not only possible but somewhat easy to define start up job dependencies such that they run one at a time in order. For example, add a bunch of units (or whatever they're called) that are just 001 - 999 and each depend on the former (so 999 depends on 998, 998 on 997, ... 002 on 001). Then, for each actual unit that does stuff, give it one dependency of the numbered startup where you want it to run (ex. sysstat depends on 001, lvs2-monitor on 002, iptables on 008, network on 010, etc).
There's probably a better/easier way to do that, but I imagine something like that would work. Having this option/example would take care of at least this concern from systemd adoption.
As a side note, this comment of yours is BS:
if understanding the dependencies is too hard for you, don't re-order them. You should not need to, it is not a normal part of system administration or software development.
If I write some daemon, I'm going to have to get it started with the system (and yes, I've written several, and it used to not be uncommon for users to do this). Under traditional sysvinit systems, something like a simple symlink to the right /etc/rc3.d/SNNservicename and I know exactly when it'll start. Yes, one could figure out the dependency tree and put it in the right place in systemd. While that's probably not all that difficult, it's certainly more difficult than "ls -1 /etc/rc3.d" and looking at the sort order.
How do prepared statements handle the not uncommon situation where you want to include an "in" clause? For example:
select * from customers where city in ?citylist
This was the problem they tried to solve by dynamically creating a statement like:
select * from customers where city in (?city-1, ?city-2, ?city-3)
So, to generate the -1, -2, and -3 parts they relied upon the index of the array.
...
for which there are no good solutions with plain prepared statements.
...
Bullshit. Psuedo code cause I'm too lazy to look up the php-ism for this:
$stmt = "select * from customers where city in (".join(',', map { '?' } array_values($city_list) ).")";
$sth = $db->prepare($stmt);
$sth->ececute(array_values($city_list));
Wrapper code to aid in building the placeholder stuff should be used to account for max count of items (generally 255 of them), after which it should split it to: ...) OR city in (?,?,? ... etc ...) )
( city in (?,?,?... etc
Does that take work? yes. Is it more effort than what they're doing? no.
... roll-your-own implementations are likely to be broken too.
As far as I can tell, this module uses custom placeholders in queries, and then replaces those with the user supplied values, building a string that can be passed to the DB as SQL without database placeholders. IE. it's not building something like:
$db->prepare("SELECT name FROM table WHERE something IN (?,?,?)")
$db->execute( @parameters );
It's building something like:
$db->prepare("SELECT name FROM table WHERE something IN ($param[0], $param[1], $param[2])")
That's always more risky. DB placeholders are not a silver bullet, but they're damn close. /disclaimer, I didn't thoroughly audit the code, so maybe it is somehow using db placeholders, but the method in question doesn't look like it is.
See line 739 here: http://cgit.drupalcode.org/dru...
Patch for users that don't want to do a full upgrade and are on 7.0 - 7.31: https://www.drupal.org/files/i...
Except that most users' connection won't be able to upload even close to 3 TB in a day.
Correct, and even the fastest aren't going to do it.
On an OC3 (156 Mbps) 3TB would take over 46 hours (almost 4 days).
On an OC12 (622 Mbps), it's about 11.5 hours.
FiOS 50/50 plan is over 6 days.
I don't know what FiOS fastest is (maybe 150/150, since someone above mentioned it), but that's still 4 days.
How many people have a dedicated OC12 at home?
...
But storage on the intranet remains miniscule and expensive. Try to get a partition big enough to build a reasonably sized virtual instance, and you'll get handed 20 Gbytes because "storage is expensive".
And so, potential customers continue to do their stuff on their own PC, because really, storage isn't that expensive.
[bold by me]
Is that really what you mean? Do you mean that when you ask your local IT for space, you get jack squat? IMO, that's their own (bad) decisions. They can easily do the same sort of thing the others are doing to provide loads of space. There's lots of ways to do it, but here's a really simple one: use a bunch of white box servers; max out their onboard SATA with largest disks you can get; stick glusterfs on them all and enable sufficient redundancy. In most cases, they'll probably still go with the vendor suggested enterprise storage and will pay through the nose for it and disks - it's sad, but it runs and then can blame someone else if there's a problem.
Or do you mean virtual servers (like linode, though they and most others have moved to 100% SSD)? They do keep upping the space, but you'd be right here.
rsync.net is swell, but the price is crazy. For example, $140/month for 1 TB.
I had to re-read it several times to make sure I wasn't misreading it. For comparison, Dropbox is $9.99/month for 1 TB.
Granted, rsync.net has a very different feature set that is very flexible. However, I wish I could pay 1/10th the cost and manage the redundancy and number of snapshots and such myself (ie. a purpose built vm with a big data drive).
Depends what state you are in.
It's probably a police state.
Even then, circumstances can alter the situation, since if you create a bunch of *huge* tablespaces on a virgin FS and they never extend, then you can get up to a high usage percentage without fragmentation.
This.
To explain it to uses that have no clue what a tablespace is, but may know what a partition is, imagine:
* setting up a separate partition for every set of similar sized files
* for very large files, give each its own partition
* pad every file in out to a fixed size
For example, for mp3's, pad every one of them to 6mb (I'm guessing; do some stats on your archive to determine optimal size).
Every time you write one, it's 6mb to that one partition.
If you delete one, there will be a hole in the filesystem, but it will be exactly 6mb.
Next time you write one, it will fill in the hole = no significant fragmentation.
In that case, you can allocate 100% of the drive. Planning for growth is left up to you, and the above isn't really a perfect description of tablespaces :-)
Back to the typical desktop, AFAIK, the 10% rule still applies. It's not for growth, it's for optimal filesystem performance. Less than that an there's not enough free space to avoid significant fragmentation under typical usage.
If you consider the above, it may be obvious that some files are worse than others at contributing to fragmentation. Log files, for example, can be awful. FS's do a damn good job nonetheless.