Comment They ought to ask about prior art (Score 1) 168
Because I suggested something very similar to CMP when Dr Dobbs was failing in slow motion: codes with the magazine to gain access to online resources.
Because I suggested something very similar to CMP when Dr Dobbs was failing in slow motion: codes with the magazine to gain access to online resources.
Nuff said.
Oracle's ludicrous claims in the Oracle/Google Android trial have shown that they are not trustworthy. Do not base your work on a base where you can be ransomed. No more Java.
Strategy is where it's at.
Microsoft and Intel are companies that have a co-dependent relationship: MS depends on Intel to bring out new chips - driving better computers, because when someone buys a new computer they pay the Windows tax. But Intel got into bed with Apple too, because being dependent on MS alone is an uncomfortable place to be; remember what happened to [fill in your own long list of companies]. So MS needed to explain to Intel who is in charge in the relationship. And spending a few million dollars to make a version of Windows which does not depend on Intel is a good way to do it. It's got other benefits too: it might spur Intel into making an i86 architecture chip and chipset that can compete with Apple A-series (something intel is not keen on doing, apparently, or we'd have seen it), it strings ARM along for a bit, it's a useful cloak for any antitrust investigation into the relationship between Intel and Microsoft, it reminds Apple that encroaching on Windows territory is a bad idea, it provides an option for future development, and it's good for PR because journalists love to talk about new goodies.
All-in-all a pretty good strategic list of why you'd want to do this. And only costing a few million.
Of course you don't want to have a properly working version because that _really would_ jeopardize the relationship with Intel. So you make sure it's incompatible with Windows-proper in a variety of ways, like being unable to run Windows programs without extra work, and you make sure that in the existing form it doesn't threaten the business market.
But maybe you privately demo to Intel versions that can do these things.
Go get a masters in CS, then apply to IBM: pretty soon now they are going to need people who have psych & CS to work with the human & animal simulations. http://www.scientificamerican.com/article.cfm?id=graphic-science-ibm-simulates-4-percent-human-brain-all-of-cat-brain
And if that doesn't interest you, your degree is most valuable in the year or so after you've gained it, until you have experience of your chosen field. If you don't want to study more, perhaps something where you can leverage the degree to gain operational IT experience - for instance something in user interface design. There are consultancies which specialise in this. Look for opportunities which leverage your degree.
Ethics sidenote: When you have simulated a brain and you killall on the processes, have you just done a bad thing? At what point is the cat simulation conscious? And should we be concerned about live animal experimentation? Now there's still a lot we have to learn about the ways that brains work - just look at the recently proposed microtubule idea for memory (can't find the original reference where I read about it, but Google shows a few results), but I think we are on the cusp of the where questions like this matter. Maybe models need aging built in, so that the cat dies a simulated death. And then there's the issue of whether keeping a conciousness in isolation is cruel. Should the simulation have simulated toys? Companions? Food?
If there was ever a site which was in jeopardy, it would be slashdot. Why is Slashdot not participating in the SOPA blackout? Does this mean that Geeknet Inc is a SOPA supporter? Please can we have a statement.
I was doing similar research a few days ago.
Some of these are already mentioned...
Other stuff:
By fixed block I mean that the file system does not search out shared data when the blocks are not on block boundaries. So if you add one byte to the beginning of a 10 GB file, and that has the unfortunate consequence of rippling up through all the blocks that make the file, then there will be no block level sharing with the original file. Of course that's a pathological case, but you get the idea.
Original poster, perhaps you could keep us informed of your findings? There's at least me who is also interested.
Firstly, he thinks that consumers are stupid: "They don’t know what they hate. All they know is they buy phone service from mobile carriers and/or buy a phone from a carrier. They love speeds & feeds and will generally buy anything they are told to by television ads and RSPs (Retail Sales Professionals)."
No: consumers ask their friends. Their friends are Slashdot readers. They know full-well what a phone Market dominated by Microsoft would look like, they know how Microsoft has behaved. Repeatedly. And they are not going to recommend a MS phone to anyone: friends don't screw friends. They all know it's just about protecting the desktop market, and the moment that MS has achieved that objective they'll screw the user. The clue is in the name: 'Windows Phone'.
Secondly: "My hypothesis is that it also enables too much fragmentation that will eventually drive end users nuts." I guess that's how it's worked out for x86 choice in the face of the Apple desktop monoculture. Nope? It turns out that we value openness. It's one of the variables we play with when making a choice between systems: given all else equal, we'll choose the system that's more open. Advantages of openness far outweigh the disadvantages like fragmentation. So all that Google has to do is keep Android at rough parity with Apple in terms of UI/features. But they are doing better than parity - it's cheaper for better.
Thirdly: Carriers know full well what happens to companies who partner with Microsoft. And so do device manufacturers. I guess some companies (cough, Nokia, cough), like the idea of handing their future to Microsoft, but it turns out that most think that's a bad idea. Sendo, anyone?
Then I'm sure we can find a bunch of people who will dispute that WP is the best technically. Form an orderly queue in the replies please.
But finally, even if you were to consider that WP was technically the best, the idea that the best tech is the winner has been roundly disproved again and again. Everyone, including Charlie Kindel, knows it's about the whole package. We all know that MS on the desktop isn't the best technically (it can't be - it has to satisfy everyone) but it is the best at the whole package.
If this research is validated, then there may be implications for UI design...
Gnome 3, for example, works using an application space focus, rather than a window focus. In one way that's quite appealing - it gives you full focus on the task at hand without the distraction of the 12 other programs you are running at the same time. The problem that lots of people have reported/commented on is that it makes it very difficult to be task focused when a task involves more than one program. Part of this may be to do with the doorway context switch impeding short term memory retention on the task at hand.
I've used Gnome 3 as an example, but it's far from alone; Metro & Apple full-screen apps spring to mind, though there's a mitigation with Apple full-screen in that it's not forced upon you.
I wonder if there's a way to enjoy the focus of application-centricity without the disadvantages? For instance, I can imagine keeping a map of the other applications visible, or a representation of the overall desktop/workspace, as you move th'rough the doorway between applications, and/or as you work in an application space. (Slashdot, you may want to vote this up so that it isn't deleted when this item is archived, so that there's some evidence of prior art when large megacorp tries to patent this UI idea.)
Something like that might be enough to jog short term memory and stop the context loss.
Or of course, we could decide that window centric works best, but work on ways to easily group windows into tasks.
Workspaces/Desktops are one way to accomplish this. The problem that I find with workspaces is that they are a clumsy way to manage tasks when I have an application that spans different tasks. But on the other hand, actively managing windows by marking and grouping them introduces unwelcome management overhead.
I would welcome a system whereby windows and applications were grouped together, either automatically or on the cue of the user, by virtue of the fact that they had been used together. (Again - oh no megacorp! - more prior art! ) For instance, one embodiment of this might be to group windows or applications based on the transfer of info between them. Cut and paste for example shows a transfer of info, and could be used as an indicator of affinity.
As ever, it depends:
Firstly, the landscape is constantly evolving, and some of what I say below reflects the current situation for Drupal 7. It may not be the same in six months time.
You need to decide:
Do you want very clean, targeted HTML and CSS? Or do you want as many options as possible in the CSS, and don't mind the cost of many wrapping divs and CSS with many overrides?
If it's the latter, then you will likely want to work from one of the starter themes, sculpting the CSS and templates to suit your design. Try the Stark (shipped with Drupal 7), Clean, Boron and Basic themes.
Or if it's the former then you will likely want to either build the theme from scratch or work from one of the minimal themes, and build up to cater for your exact requirements. Omega, Zen, Adaptive, Genesis and Fusion are all good bets.
You need to decide whether your design is grid-based or not. If it is grid-based, then it's easier to use a theme with built-in grid support. (Or you can add grid support to a theme which doesn't have it.) If your design is not gridded, then you are probably best-off not using a gridded theme (though of course you could override the grid classes to remove the grid.)
If it's grid-based, then the best is probably Omega, but 960 is worth a look. For non-gridded, Stark, Clean, Basic, Zen, Adaptive, Genesis and Fusion are all still ok.
You need to decide whether mobile support, HTML5, and adaptive theming are critical or not. Of course you can override the templates a theme provides, to include any of these, but starting off with a theme with them built-in will be easier for most people.
If any of these are critical, and you aren't interested in building in support yourself, then Omega, Adaptive, Genesis, Boron and Fusion have support for some or all of these features.
At the moment, if a maximal theme, with grid support is what interests you most, Omega is the best imo. The cost is that it's big, and complex.
There are several good resources:
http://drupal.org/node/323993 contains a list of starter themes.
http://www.chapterthree.com/blog/squiggy_rubio/review_drupal_6_starter_themes - is about Drupal 6, but much of it remains relevant for Drupal 7.
And in some blatant promotion, sometime in the next week we'll post an article at http://www.tanasity.com/ comparing and contrasting the best starter themes for Drupal 7, the work on which this note is based.
Before doing this you may want to check what the local laws are. Police States do not like privacy. Encryption is not always legal. If you find it's illegal you will probably also want to check what the penalties are.
As any veteran of website Content Management Systems (CMS) will tell you, the problem is that custom coded sites are a nightmare in waiting for most customers. Unless you have a mega budget, and a team of developers, and the guarantee of the ongoing budget and team, you are much better off using a existing CMS. The security is likely to be better than with a custom CMS especially if there are lots of people contributing, the opportunities to grow the site through new functionality will be better, especially if it's open source, and the cost is likely to be less for more.
Behind the scenes most of CMS there is a database. Often, but not always, it's coupled to a scripting language, and usually it's organized in such a way that it's modular. This modularity is what gives non-custom CMSs their teeth, but compared to custom CMSs, the cost is that the queries on the database are non-optimal. Often data is read twice or more by different parts of the CMS because they aren't able to directly work together to retrieve the data in the way that a custom CMS can. It's this explosion of database queries which is usually responsible for any drop in comparative speed, and not the cost of executing scripts.
The revolutionary approach is not to waste time redeveloping stuff that other people have already built, but to reuse at low or no cost through the power of open source. It's almost always quicker, easier and cheaper to buy faster hardware and use a scripting language than it is to develop software in C++.
Some games and operating systems may be written in C++, but they have different needs and requirements, and operate in different environments; a formula 1 car is optimized for traveling around a race circuit, but it is useless when there are speed bumps.
Drupal represents tens of millions of dollars investment and is built by some of the world's best CMS developers. It takes a lot for a custom CMS to compete with that.
Disclosure: I'm involved in the Drupal project. I develop for Drupal. I've been developing for Drupal for 6 years. I have programmed in C++ and scripting languages. I have built custom CMSs. I've built sites in other CMSs. I threw away my CMS framework when I discovered Drupal, not because it was better, but because, even where it wasn't, the rate of growth of Drupal meant that it soon would be. The rate at which Drupal is developed far outstrips anything that all but the very largest companies can sustain. I would say that I'm a CMS veteran of contemporary CMSs. Whatever that means.
And I'd like to take this opportunity to advertise - Drupalcon Chicago will be in March 2011. And if you are in Europe, I have it on reasonably good authority that you can look forward to the announcement of the location of the Autumn conference either later this week or next week. And this week we moved the Drupal.org site redesign live.
I think I can claim to be a real programmer having designed & written shrinkwrap software, built in-house corporate software, developed embedded control software, made web apps used by thousands of users daily, written several frameworks, all for software running on a diverse range of hardware, from microcontrollers through to mainframes and most things in between, in a pretty wide variety of languages, from systems languages like C, through to dynamic languages like PHP and Ruby, and all the usual suspects in between.
In my opinion Drupal core is well written. Tons of thought goes into it, with lots of smart, experienced people weighing in on the architectures and reviewing the code. It's (far) better than most closed source apps I've had the pleasure of working with.
This is also true of the top, say 10 to 20% of non-core modules. The ones that no serious site is without. The quality of the rest varies hugely, from bad, through to awesomely good.
Drupal is not alone here. This is a problem with almost all except the simplest CMSs.
The problem is one of complexity: when you are doing one thing, it's easy to optimize it into one SQL query. But when you have a modular system, you want each module to work independently as much as possible because you want to avoid dependency hell, and you want to minimize module interaction because that will lead to side-effect bugs which are difficult to track down. The architecture choice that most CMSs make in order to foster sustainable growth is that each module gets to handle its own data. But that means that you don't get optmized database queries - in fact you are almost certainly guaranteed that you will have multiple reads of the same data, as different modules work on that data.
Which is why all mature CMSs also have caching strategies. They typically cache the output of whole pages if pages do not differ by user, and partial pages where they do, constructing the page from the appropriate parts. They also usually have in-memory caching strategies to avoid repeated db reads.
Better CMS's have variable caching strategies, allowing you to store pages in memory, in files and in database as appropriate. Drupal has modules for all of these strategies and also works well with Varnish, a caching proxy/accelerator.
With your bare hands?!?
