Research has shown that between complicated 8 character passwords and basic 16 characters, it takes far fewer tries to generate 16 character passwords, and fewer typos and passwords forgotten, while having the same estimated entropy. It makes a bit of sense; many of the special characters are harder to type. I suspect with mobile, the effect is even more pronounced.
Maemo Linux, the OS that runs my n900, runs Xorg just fine. I don't think GNOME would be a good fit, but Hildon does use GTK, dbus, hald, pulseaudio, NetworkManager, and the evolution DB backend. And while you can't run amd64.deb, it does have a repository of ARM arch.debs. I think the best way to define what Slashdot would call linux is "capable of running wireshark". And the N900 meets that task, but does hilight your point that desktop apps are not in and of themselves, ready for mobile. I think the opposite might be true though; things that work on phones should be able to work natively on desktops without much fuss.
Maemo goes back to the n770 in 2005, so Android is hardly the first ARM phone attempt. Frankly, the reasons for success and failure here don't involve Linux technicals. It's about market position and strategies. Nokia has so many base patents on cellphones that they feel entitled to dictate the pace of phone growth. Their Maemo smartphone strategy assumed a leisurely 5 years and a patent portfolio to stop competition from racing ahead. Well that didn't stop Apple, or Google, and Nokia is happy to collect their profits in the form of patent settlements instead, while the board of directors approves a backdoor sale of Nokia to Microsoft.
Apparently this is deliberate. I can see their point, a lot of games with "good AI" are basically impossible to beat on easy. But it's kinda annoying to have a civilization constantly impaling themselves on your wall of pikemen etc.
It's more like an opportunity to create a storyline where Google fails and Baidu succeeds. Even the linked article offers it up: Baidu outcompetes Google, forcing them to close shop in China. Now they're going to succeed where Google has misstepped. Or something.
One of the challenges with generating and using data sets is cleaning them up. Data entry errors, OCR failures, conflicts between multiple sources, etc. make it a pain to search and summarize data. Gridworks helps me hunt down bad records and normalize fields. If it keeps improving, people might start using it before publishing their crap data.
Ironically, the purpose of the law, as I understand it, is to prevent oppressive regimes from recruiting companies to collect information about the citizenry.
And if you narrow "North America" down to US, there are two 3G GSM networks. which means it works of half of the networks available to me. According to that list, Canada is roughly 1/3rd. The question you might ask is why there's two bands to begin with.
OEMs do. Canonical's business operations are largely opaque to the community. Sources of revenue I've discovered include: OEMs like Dell buying engineering support contracts for their Ubuntu laptop/netbook offerings, hardware manufacturers paying Ubuntu to port to their new platform, and OEMs like Toshiba paying Canonical to run certification testing.
For netbooks, faster boot and performance is a feature worth pursuing. At this point all I've seen is Scott mention they'll try it and test it before the point of no return that comes with time based releases.
In part it depends on the kinds of programming you want to apply for. There are three kinds of programs:
1. Simple programs that largely revolve around "business logic" and writing and reading from a database. The most complicated stuff is either modeling the whole damn business process or maybe generating some reports. This stuff CAN become complicated, but I treat that as a design flaw. You will have a hard time getting into this without HR buzzword compliance. I think they're doing you a favor. Lots of poor CS students and business/IT majors end up in this place. 2. Simple programs that have complicated results. Lots of EE work revolves around designing simple circuits or programs and demonstrating they satisfy certain engineering properties. Control loops and whatnot. The programs are simple but the consequences may involve differential equations or recurrence relations. The programs are generally a variation of a small set of algorithms, with parameters tuned for your design's requirements. This is where EEs turned programmers generally end up. 3. Complicated programs. Wicked applications of math, like Hidden Markov modelling, or optimizing compilers, language theory and software verification. Speed reading CS won't count here, as you need to deeply understand the principles of computers and programs before you'll be productive here. If you've written a Fast Fourrier Transform implementation in school, you might have a shot. Otherwise, top CS students and grad students only.
So my advice is to find firms that do place EEs into programmer roles. Embedded systems places mainly. I have many EE friends that landed in programming roles, even though they insisted they would fight the trend. Try to position yourself in your current EE employment to work alongside programmers, learn what they do and pick up a few tasks for them. Eventually your CV will have programming related material to pull from for a targeted resume. And you'll have the friends and contacts to pass your resume directly to hiring managers for consideration.
If you're after category 3 work, consider getting graduate degree (don't waste your time on another bachelors). Plenty of EEs go back for different degrees. Look for institutions with EE and CS in one department, and I personally recommend against financing it. Spend 10s of thousands of someone else's money earning an advanced degree. There's TA positions, research positions, scholarships and employer paid options. Be prepared to sacrifice some portion of your life; be it your family, your career or your sanity.
When I TA'd for an advanced undergraduate level OS design class, we used team based projects for instruction and the best weapon we had against freeloading was secret peer evaluation and interrogation about the code. There's a lot of good reasons to go for collaborative design projects. They're closer to real world assignments; when you run into a problem with three people coding, chances are one of them can figure out the typo or think-o. The best students use it as an opportunity to test out revision control systems in collaborative fashion.
I think a lot of students skip the course now because it's been made optional and famously hard. With some effort it could be salvaged into a quality Software Engineering practices course covering revision control, automated builds, testing, static analysis and the engineering implications of NP completeness in operations theory.
You would have a point had it been done for technical reasons. And had you known what you were going on about. Maemo was never based on clutter, it predated clutter by several years and the hardware it ships on lacks 3d acceleration.
Sadly, it seems you're also out of date. Maemo5 features 3d effects, to great use. I'm not sure whether clutter was in the final design, though.
SSL/TLS at it's core generates "session keys" for communication; a string of random characters. It's possible they're trying to deplete the SSL servers of true entropy for some undisclosed attack; PRNG, for example.
Maemo5 has Ovi Maps for Maemo 1.0. No turn-by-turn, etc. No bookmarks or voice announcements. In my experience it's pretty poor for on the go navigation.
Slashdot Mirror
Research has shown that between complicated 8 character passwords and basic 16 characters, it takes far fewer tries to generate 16 character passwords, and fewer typos and passwords forgotten, while having the same estimated entropy. It makes a bit of sense; many of the special characters are harder to type. I suspect with mobile, the effect is even more pronounced.
Actually, JPMorgan invented the CDO and got out of them after they decided they were too risky and dangerous.
Well, when you're talking about a company that earns 6 billion a quarter, a 3 billion of investment annually still leaves plenty of room for swimming.
Maemo Linux, the OS that runs my n900, runs Xorg just fine. I don't think GNOME would be a good fit, but Hildon does use GTK, dbus, hald, pulseaudio, NetworkManager, and the evolution DB backend. And while you can't run amd64.deb, it does have a repository of ARM arch .debs. I think the best way to define what Slashdot would call linux is "capable of running wireshark". And the N900 meets that task, but does hilight your point that desktop apps are not in and of themselves, ready for mobile. I think the opposite might be true though; things that work on phones should be able to work natively on desktops without much fuss.
Maemo goes back to the n770 in 2005, so Android is hardly the first ARM phone attempt. Frankly, the reasons for success and failure here don't involve Linux technicals. It's about market position and strategies. Nokia has so many base patents on cellphones that they feel entitled to dictate the pace of phone growth. Their Maemo smartphone strategy assumed a leisurely 5 years and a patent portfolio to stop competition from racing ahead. Well that didn't stop Apple, or Google, and Nokia is happy to collect their profits in the form of patent settlements instead, while the board of directors approves a backdoor sale of Nokia to Microsoft.
I noticed you're affiliated with KSU. Have you seen K-SLUG? (#k-slug on freenode!)
It's about Maemo, the last, best hope of the true linux phone.
Or you can let them in an hour early for a fee. Or better yet, wait for the library to just ship everything to amazon.
Apparently this is deliberate. I can see their point, a lot of games with "good AI" are basically impossible to beat on easy. But it's kinda annoying to have a civilization constantly impaling themselves on your wall of pikemen etc.
It's more like an opportunity to create a storyline where Google fails and Baidu succeeds. Even the linked article offers it up: Baidu outcompetes Google, forcing them to close shop in China. Now they're going to succeed where Google has misstepped. Or something.
One of the challenges with generating and using data sets is cleaning them up. Data entry errors, OCR failures, conflicts between multiple sources, etc. make it a pain to search and summarize data. Gridworks helps me hunt down bad records and normalize fields. If it keeps improving, people might start using it before publishing their crap data.
There's a lot of jobs on the coasts, where costs are higher and annual wages compensate for this.
Ironically, the purpose of the law, as I understand it, is to prevent oppressive regimes from recruiting companies to collect information about the citizenry.
And if you narrow "North America" down to US, there are two 3G GSM networks. which means it works of half of the networks available to me. According to that list, Canada is roughly 1/3rd. The question you might ask is why there's two bands to begin with.
No amount of undervolting an opteron is going to surpass power draws of NAS's based on ARM processors.
OEMs do. Canonical's business operations are largely opaque to the community. Sources of revenue I've discovered include: OEMs like Dell buying engineering support contracts for their Ubuntu laptop/netbook offerings, hardware manufacturers paying Ubuntu to port to their new platform, and OEMs like Toshiba paying Canonical to run certification testing.
For netbooks, faster boot and performance is a feature worth pursuing. At this point all I've seen is Scott mention they'll try it and test it before the point of no return that comes with time based releases.
In part it depends on the kinds of programming you want to apply for. There are three kinds of programs:
1. Simple programs that largely revolve around "business logic" and writing and reading from a database. The most complicated stuff is either modeling the whole damn business process or maybe generating some reports. This stuff CAN become complicated, but I treat that as a design flaw. You will have a hard time getting into this without HR buzzword compliance. I think they're doing you a favor. Lots of poor CS students and business/IT majors end up in this place.
2. Simple programs that have complicated results. Lots of EE work revolves around designing simple circuits or programs and demonstrating they satisfy certain engineering properties. Control loops and whatnot. The programs are simple but the consequences may involve differential equations or recurrence relations. The programs are generally a variation of a small set of algorithms, with parameters tuned for your design's requirements. This is where EEs turned programmers generally end up.
3. Complicated programs. Wicked applications of math, like Hidden Markov modelling, or optimizing compilers, language theory and software verification. Speed reading CS won't count here, as you need to deeply understand the principles of computers and programs before you'll be productive here. If you've written a Fast Fourrier Transform implementation in school, you might have a shot. Otherwise, top CS students and grad students only.
So my advice is to find firms that do place EEs into programmer roles. Embedded systems places mainly. I have many EE friends that landed in programming roles, even though they insisted they would fight the trend. Try to position yourself in your current EE employment to work alongside programmers, learn what they do and pick up a few tasks for them. Eventually your CV will have programming related material to pull from for a targeted resume. And you'll have the friends and contacts to pass your resume directly to hiring managers for consideration.
If you're after category 3 work, consider getting graduate degree (don't waste your time on another bachelors). Plenty of EEs go back for different degrees. Look for institutions with EE and CS in one department, and I personally recommend against financing it. Spend 10s of thousands of someone else's money earning an advanced degree. There's TA positions, research positions, scholarships and employer paid options. Be prepared to sacrifice some portion of your life; be it your family, your career or your sanity.
When I TA'd for an advanced undergraduate level OS design class, we used team based projects for instruction and the best weapon we had against freeloading was secret peer evaluation and interrogation about the code. There's a lot of good reasons to go for collaborative design projects. They're closer to real world assignments; when you run into a problem with three people coding, chances are one of them can figure out the typo or think-o. The best students use it as an opportunity to test out revision control systems in collaborative fashion.
I think a lot of students skip the course now because it's been made optional and famously hard. With some effort it could be salvaged into a quality Software Engineering practices course covering revision control, automated builds, testing, static analysis and the engineering implications of NP completeness in operations theory.
I guess the next question is, isn't disclosure the sort of thing the CISO signs off on?
We can't get developers to pay attention to compiler warnings, what makes you think users are going to fare better?
Ironically, people who pay at the pump are least in need of any clerk at all.
No, this is a dumbed down version of civilization. CivRev was just a multiplayer game that could potentially finish in under a lifetime.
Sadly, it seems you're also out of date. Maemo5 features 3d effects, to great use. I'm not sure whether clutter was in the final design, though.
SSL/TLS at it's core generates "session keys" for communication; a string of random characters. It's possible they're trying to deplete the SSL servers of true entropy for some undisclosed attack; PRNG, for example.
It is a bit thicker. But I kinda doubt that it matters much.
Maemo5 has Ovi Maps for Maemo 1.0. No turn-by-turn, etc. No bookmarks or voice announcements. In my experience it's pretty poor for on the go navigation.