Arduino is a good suggestion. I would add some basic Olimex ARM7TDMI boards to this, maybe BeagleBoard kits with Linux on SD cards. Maybe a basic FPGA kit. As comprehensive kits with everything needed to get up and running using a PC. Install software, plug in the power, open any of the example projects, and hit go. A basic DSP kit would be popular too I'm sure. A DYI digital/networked/SD card picture frame that runs Linux/Android with a touch display. It's not about money either; RS has never been that cheap. It's about educational value and lowering the barrier of entry.
Of course, SparkFun Electronics (sparkfun.com) has pretty much this segment locked up...
It honestly acts more like Malware than anything, so it'll be interesting to see how Microsoft deals with it since it sells ISA (and now Microsoft Forefront Threat Management Gateway 2010) this seems like the two are going to be at loggerheads.
Ten is really low - it could reasonably be someone who can't remember their username and/or password. I like to ban at 250; if you get up that high you're pretty much bound to be running some sort of automated attack, while it's still not high enough to have a non-trivial chance of success for a dictionary attack.
A photographer in my local market offered a similar groupon and I did the same calculations as the author of this article. The girl wound up selling enough to work for 5 months, 40 hours a week for an $1800 GROSS profit. So that's before paying for equipment, insurance, phones, computers, etc.
$1800 may be enough for someone in their early 20s to subsist on while putting sweat equity into a business. The value of a service business is in the traffic through the front door - once people come in you can work with it. Up sells, return business,go find partners and investors, create partnerships with other businesses, sales deals, promotional deals, work various leverages. It's the capital in a sense. For a photographer there's also a matter of exposure (not only of their work, but also to the market), developing a portfolio, and work/business experience. Lots of young people work for peanuts for these reasons - I've done it, too. As a learning experience and to get a foot in.
For the last point, consider if he has say a UKP 6000 marketing budget. If he figures the net loss on each groupon response is UKP 20, then he can afford to make 300 of those within his budget. However, if there's no response it hasn't cost him anything - and he still got some exposure. Groupon is attractive because it's like running a campaign where you only have to pay when people show up at your door.
Yeah my guess is he's got to be hoping for upsells of some sort. Doing this much work for "free" is basically just getting his foot in the door, which may be more than he had before. Perhaps it will work out or perhaps it won't. Time will tell I suppose.
I think the time and cost is overestimated - if he uses location pack lighting and a backdrop, then very little editing or retouching will be needed. Most shots will simply look good using a common recipe out of camera using a tool like CaptureOne Pro or Lightroom. With professional lighting there's no need to spend any time at all in post; he would if he were an agency, but for what people pay for they'll get perfectly professional quality results. The author is a photojournalist, and as such probably isn't used to work with location lighting, but with available light which is more a matter of luck if you get something decent out of camera. As for printing, either he has a volume deal with a lab or he does his own. Any professional RIP makes it close to zero cost in time, and materials are low to make such small prints. If he wasn't set up before he will be after this.:p
So while I don't think he's making enough to meet payroll on this, the costs are overstated and no way would it take a year.
Finally, if he has an established studio business with commercial clients and wants to branch out, what's the cost of running magazine ads and other promotions? What's the purpose of those ads... to build brand recognition and to get people to try it. Here he gets a guaranteed response ("click through to buy"), lots of exposure, and payroll can be met with the advertising budget.
And not everyone needs an FC to SAN connection that can transfer the equivalent of a non-compressed movie in a few seconds.
Well, yes and no. YOU don't need it, but FC is switched and may be shared with other systems. Like production systems. They might prefer if you transfer at full bandwidth so you spend less time occupying the infrastructure. For just one computer and a bunch of drives in a tray I don't see any need for FC in the first place; eSATA would handle that just fine at a fraction of the cost and complexity.
So exactly where do you buy your Thunderbolt graphics cards?
DisplayPort devices appear like nodes on a Thunderbolt network, so you can theoretically use any DP graphics card or display. Presumably Apple routes the DP output of the graphics card to the TB host switch. Depending on whether they use a stock DP cable you might be able to plug in any card that fits and has an OSX driver and firmware support - the latter if you care about it showing something during boot, but since systems pretty much only reboot on Software Updates anymore this may not really matter. If they use a custom cable you may need an adapter, a special cable, or the card won't work.
Why is so much in the cloud? I've heard it touted in lots of marketing speak, but I've never worked with it.
As someone who has never worked with the cloud (shocking, I know), what are the advantages and disadvantages?
Is it basically just distributed scalable redundant web hosting run by a big company? So you're basically renting to avoid the start-up capital costs of those services and to put them in the hands of specialists, while you focus on your web apps?
Or is it more?
There's a big mix-up of lots of different concepts and ideas here, to the point that the questions you ask are impossible to answer.
- EC2 is a vps-like virtual server provisioning service. You rent a virtual server instance by the hour. APIs exist for you to dynamically add and remove instances as needed. You create an image, then can fire up additional instances as you see fit. Someone like Netflix for instance, can fire up streaming servers during peak hours then shut them down at off hours.
- You can of course set up your own co-lo systems, but it will be provisioned 24/7 and will cost you more since it will be sized for peak capacity, and even during peak most of the servers will be idle much of the time due to random load variance. You can improve peak utilization by setting up your own virtual provisioning. But then you have ops costs, so unless you have a massive operational scale you'll find it cheaper to buy from AWS (or linode, rackspace, etc).
- EBS is a logical volume service. You create a volume and mount it on an EC2 instance. Like with server instances, there are API calls to dynamically create EBS volumes. You can unmount it and move it to a different server in the same datacenter, so you could use them for instance to take backup snapshots or log analysis, or similar, in addition to simply being server storage. Of course you get to build or buy the software to do all these things yourself.
- Server instances belong to groups, and have access controls set up among them. This allows you to create private 'backplane' interconnects, where some things like sql servers are only accessible to instances part of a group.
- EIPs are elastic IPs, which are IPs you lease and can then assign to any of your server instances (usually ingress and point-of-contact servers). You can move them between virtual servers as you like, and obviously would typically map DNS to them. Servers will otherwise get anonymous IP addresses, meaning they get something arbitrarily assigned. They're reachable (if you wish) from the net at large, but aren't well-known points for your service.
- AWS also provides a load distribution service. I've never used this actually; it never seemed to fit right.
- S3 is a cloud service, meaning it has no deterministic ingress and egress. It's used for content distribution: writing is expensive, reading is dirt cheap. Content stored is automatically replicated and de-replicated as needed. You have no idea where it lives, in how many copies, and how it's backed up. SLAs make promises about availability.
- Content distribution is a poster child cloud service example. Not all services will easily fit a cloud model. Many other services that have fit the model (mainly using mapreduce or like) are batch processing based and more about massaging massive amounts of data than interactive end-user services.
- Somewhat simplified, if your service can fit around a key-value store (even a sophisticated one like MongoDB), then it's a candidate for a cloud architecture.
- There are plenty of providers of bits and pieces to do things like server monitoring, cost analysis, and automated/manual server provisioning. In fact, I'm getting into this business myself...
A 'cloud' service is not a hosting service - it's a way to build things, a black-box mindset. There may be a well-defined point of contact (perhaps found via DNS), but beyond that everything is dynamic. The initial contact can redirect, either explicitly or implicitly. It's not like a 'hosting' service where you click a button and get a Joomla host. But it might be a viable way to implement such a hosting service.
21 inches = 1 foot 9 inches. Oops. But exactly the same error happens when people add up strings of decimals and I really don't think there's any difference to speak of.
Can you quickly calculate in your mind:
(2 miles) + (321 yards, 1 foot, 5 inches) + (2 yards, 1 foot, 1 inch) + (5 feet, 9 ich) + 6 inch?
In metric... it is a no brainer.
It's pretty much a no-brainer in imperial as well. You add 6+9+1+5 inches (21 inches = 1 foot 11 inches), 1 + 5 + 1 + 1 feet (8 feet), 2 + 321 yards (323 yards), and 2 miles. So, 2 miles, 323 yards, 8 feet, and 11 inches. No harder to add up than 2km + 321.15m + 2.11m + 0.059m + 0.006m. A paper and pen helps of course.
What *really* confuses me about sanitary pipes is that a 3" pipe is 3.5" wide. Errr.... what?
It's intended to fit a 3.5" hole. The inside is standard (so you get smooth joints with other 3.5" pipe), the outside depends on how thick the wall is, which depends on the material it's made from. All you really care about is that the inside can smoothly join with other 3.5" pipe and the fact that it's 3.5" or less in diameter - so it can fit existing holes and conduits, and replace existing 3.5" pipe. If this is all a grand revelation, then I strongly suggest hiring a professional rather than DIY...
If you had taken a quick look at the link you provided, you'd have seen this graph that shows how temperatures rise very quickly after an ice age and then slowly creep down over millennia.
If we are in an interglacial period, climate should be cooling, not warming.
I see about one degree per 10000 years on the upswing. Sustained over a century or more, one degree C per 25 years means it's 25/10025 = 0.25% caused by interglacial warming and 99.75% something else. Or, rounded to the nearest integer, 0% and 100% respectively. Clearly, finding out what this 'something else' is rather than pretend it doesn't exist would seem to be prudent.
There is a reasonably straight forward technical solution, that could be implemented in a future SSL protocol, to resolve the issue of trust when you already have an account on a site. A host site can add the hash of your password to the symmetric key used after the key exchange, your browser can then do the same on your side. This is essentially using a a shared secret (the hash of your password) as part of the symmetric key.
I like this. In addition, when logging in there's no reason to send the password, when it could be hashed with a random initialization vector. All the browser has to send is proof of knowledge of the password, not the password itself. The password only needs to be sent verbatim when it's changed and during registration. This overcomes a weakness in your proposal, namely that your scheme requires authentication to set up the connection; so it can't be used for the authentication itself. The site also needs to provide a challenge to prevent playbacks, I suppose that could be part of the IV.
Another possibility, to get rid of CAs, is some process of trusted referral. If I'm authenticated with a site I trust, then it can provide me with a token and validator for another site; I send a hash of the token and a random number to the site, which responds with a response and random number. I hash the validator with the random number of compare it to response. If it matches, I consider the site trustworthy and register with it. Once registered, it will be able to prove it's the same site I registered with (as per your suggestion above). This would require the formation of a web of trust. If felt super paranoid I could even get a site's token-validator pair from a couple of randomly selected sources in different countries, just to corroborate.
I've been working with mongo noSQL for a little while now, and it's nice because it's fast and you don't have to de-normalize data that should not have been normalized in the first place.
I totally agree with this. MongoBD is great, but so are RDBMS. They serve different functions. The problem I have is with SQL. It's a language, not a data model or representation. In addition, the server sits at the end of a socket and acts like it's an interactive terminal session, using a human-friendly language, one command at a time. This means for instance that the server has to perform queries in the order issued on any one connection, but there is no guaranteed order or way to state dependencies over multiple connections. As opposed to say having a single connection with a protocol (not some chatty terminal session), asynchronous, based on something as trivial as BSON serialization and JSON-RPC. I'm just tossing these up as simple examples (and ones I'd personally think would be miles ahead). THEN, for maintenance you create an interactive utility that parses a human-friendly query language that could smell and taste like SQL. What amazes me about the effort in the MS researchers' paper is how they try to create another language for non-ACID uses, which I find totally backwards - they should eliminate the language part of RDBMS!
Just look at what happens when a query is made:
1. A textual representation of the query is made, vulnerable to injection attacks or plain errors. Human-readable, as usual, is inherently inefficient.
2. Thread stuffs query object in a queue and blocks waiting on it (on an event object/condition variable that's part of the query)
3. Thread from SQL worker pool wakes up (on queue change event) and picks up request
4. SQL pool thread sends text to DB server and blocks waiting for a response
5. The process reverse on the server via a reactor pattern
6. Server sends back human-friendly reply
7. SQL pool thread wakes up and picks up response, and parses it (it has to look for errors)
8. SQL pool thread tacks response to query object, signals a change to it, and goes to pick up the next query or sleep
9. Application thread wakes up when query is signaled
10. Application thread parses the reply (second time, because it knows what the query is which the SQL pool thread doesn't, unless it were to parse the query)
Compare this to:
1. Application builds data representation of query, either by building a simple tree from scratch, or using an algorithmic tree transform on a more complex set of data. If data isn't natively in BSON or whatever is used, then it's transcribed.
2. Application thread grabs lock and adds RPC envelope to query, registers the RPC ID, writes RPC object to server socket, releases lock
3. Application thread waits for query to complete, by volunteering to service the reactor (if no other thread already does)
4. A response comes; the RPC ID of the original call is looked up, the query object retrieved, the response envelope removed, and the response tacked onto the query
5. The calling thread is woken up. If there's only one thread making queries and the reactor doesn't have a dedicated service thread (or pool), then this is the same thread that waited in select/poll/epoll/kevent(), and it's simply returning.
6. Data is deserialized, if needed.
If you're a programmer you can immediately see why SQL is such a massive complexity on top of what is really a pretty simple problem with a simple solution. The number of connection to juggle, service pools, blocks/unblocks, context switches, parsing and serialization spread all over, poor layering, fits poorly with asynchronous applications, etc etc. In fact, there's actually nothing wrong with SQL per se, the problem is that it's not needed in the first place any more than a program should call a subroutine by emitting text for it to substitute parameters, then compile and run it! That doesn't mean there's anything wrong with compilers!
1) You start out observing something the current theory can't explain.
2) Come up with a new theory that accurately predicts all experimental results so far, the newly observed effect, and that also predicts something new that has not been tested yet.
3) Test the new thing that the new theory predicted. If you do observe the new effect, it lends credence to the theory.
Except, of course, it's a hypothesis until 3 has been repeated a few times by different people; in particular by critics looking to disprove it. After it stand up to this scrutiny and organized efforts to disprove it actually fail, in the process proving it, it becomes a theory. Theory means only theologists will argue against it. But in vernacular use, theory = hypothesis.
No, the story is far from out as to what the hell is going on, but the levels have reached well beyond what we were not worry about "because it isn't this high". Let me post once again the link to xkcd's excellent map of radiation levels.
http://xkcd.com/radiation/
This is really only relevant to full-body irradiation. The energy goes up with the inverse square of the distance to emitter - for a cosmic source this is irrelevant. But for a tiny radioactive dust speck it makes a big difference. Inhale it and it gets stuck in your lungs. The tissue immediately surrounding it (at microscopic distances) gets nuked and cell death ensues. In effect, you get a tiny lesion. Normally, when you get radiation burns you remove yourself from the source and heal up. But with the inhaled dust speck it sits there, with no chance for reprieve; when your body responds with inflammation and fibroblasts it gets continuously nuked. Scarring builds up. It's like you pick a scab year after year and won't let it heal. Eventually the lesion gets chronic and cancerous and begins to spread. You really don't want to seed your organs with radioactive isotopes. This is also why Potassium (which is radioactive) is harmless - it's water soluble and gets flushed out. Iodine collects in the thyroid, strontium in bones (it's a calcium analog).
The Sievert scale approximates physical injury - but it only works for large-area irradiation, not long-term exposure at microscopic distances. In this context, even a dental x-ray is immensely broad-area and assumes a distant emitter. Alpha radiation is weighted to adjust for epidermal protection. For higher intensities it also assumes brief exposures and that the body is given an opportunity to heal.
The bad faith isn't in losing the laptop, it's in the BP policy allowing workers to have this information on laptops that can be lost.
At least without crypto to protect it. I keep a lot of sensitive paperwork (contracts, etc) on my laptop, but it goes in an encrypted file system that's only mounted as needed, then unmounted.
Emacs runs just fine natively on OS X. I build my own, but there are lots of binary packages. I do a fair amount of python code; works fine, too. HOWEVER, for projects that involve databases, Apache, custom Apache modules, mod_python, and OS specific optimizations I use a VM. The reason isn't just one of compatibility or applicability, but of sane containment. I don't want all this stuff on my everyday system; I WANT it contained in a VM. When I suspend the VM I suspend this entire assortment of servers. If I screw up the configuration I can easily roll it back to a previous snapshot. The great applicability - meaning I can run a kernel and system configured exactly as the target server I plan to deploy on - is icing, though obviously quite important as focus switches from functional to performance and stability, and to fixing system-specific issues or crafting package install scripts. Usually one VM for development and one for testing - the latter checks that there are no dependencies on having dev tools installed (which a deployment server won't). For different projects you'll then obviously set up different VMs, so they won't step on each other.
Um. No. Many modern libraries or "frameworks" (newfangled word for library) are OO. Most OSes remain written in classic system programming languages like C and assembly language. In fact, most frameworks start as object oriented wrappers for certain OS calls and cruft up from there.
A framework is a collection of libraries and other resources, like daemons and agents. The C runtime (including crt0.s etc) can be said to be a framework. In fact, "runtime" is closer than "library". You could say, for instance, that the is a Core "runtime", a UI gadget "runtime", a Windowing "runtime", a "video rendering" runtime, etc - but it's a bit weird conceptually to have multiple runtimes. Enter the term Framework. In older days we used to call these "layers" and similar, but Framework is more general and doesn't paint you in a corner where you're forced into layering violations just to get something to work. A Framework may also include daemons, like a UI manager, SNMP agent, or such.
That's very interesting. To elaborate on your post, I think it would be very useful to have a native python compiler backend that's fed an RTL-like intermediate structure. Out comes a blob of machine code with a module interface. It doesn't have to be quite as low level as GCC RTL, but could be something closer to C++ with typing, function names, variable names, etc, so closer to the front end. (It could be expanded to GCC-like RTL in a first step of course.) Hooks could be used to apply application-specific optimizations. It should be quite possible to use gcc as a starting point for this.
Yeah. The phrase "trade school" shouldn't be seen as a bad thing. At the end of the day it comes down to egos. People want to be seen as smart. If someone went to a trade school, and another to university, people will think the university kid is smarter.
The purpose of trade schools is to teach a practical vocational skill to someone who isn't intellectually top shelf but who can still perform many jobs just fine. An auto technician/mechanic would be a good example; they can diagnose and fix most problems. But you don't expect them to be able to design auto parts; designing an engine is a whole different ballgame than fixing one. Automotive engineering is not a vocational trade.
Slashdot Mirror
Arduino is a good suggestion. I would add some basic Olimex ARM7TDMI boards to this, maybe BeagleBoard kits with Linux on SD cards. Maybe a basic FPGA kit. As comprehensive kits with everything needed to get up and running using a PC. Install software, plug in the power, open any of the example projects, and hit go. A basic DSP kit would be popular too I'm sure. A DYI digital/networked/SD card picture frame that runs Linux/Android with a touch display. It's not about money either; RS has never been that cheap. It's about educational value and lowering the barrier of entry. Of course, SparkFun Electronics (sparkfun.com) has pretty much this segment locked up...
It honestly acts more like Malware than anything, so it'll be interesting to see how Microsoft deals with it since it sells ISA (and now Microsoft Forefront Threat Management Gateway 2010) this seems like the two are going to be at loggerheads.
MS will probably be pushing UPnP.
Ten is really low - it could reasonably be someone who can't remember their username and/or password. I like to ban at 250; if you get up that high you're pretty much bound to be running some sort of automated attack, while it's still not high enough to have a non-trivial chance of success for a dictionary attack.
A photographer in my local market offered a similar groupon and I did the same calculations as the author of this article. The girl wound up selling enough to work for 5 months, 40 hours a week for an $1800 GROSS profit. So that's before paying for equipment, insurance, phones, computers, etc.
$1800 may be enough for someone in their early 20s to subsist on while putting sweat equity into a business. The value of a service business is in the traffic through the front door - once people come in you can work with it. Up sells, return business,go find partners and investors, create partnerships with other businesses, sales deals, promotional deals, work various leverages. It's the capital in a sense. For a photographer there's also a matter of exposure (not only of their work, but also to the market), developing a portfolio, and work/business experience. Lots of young people work for peanuts for these reasons - I've done it, too. As a learning experience and to get a foot in.
For the last point, consider if he has say a UKP 6000 marketing budget. If he figures the net loss on each groupon response is UKP 20, then he can afford to make 300 of those within his budget. However, if there's no response it hasn't cost him anything - and he still got some exposure. Groupon is attractive because it's like running a campaign where you only have to pay when people show up at your door.
Yeah my guess is he's got to be hoping for upsells of some sort. Doing this much work for "free" is basically just getting his foot in the door, which may be more than he had before. Perhaps it will work out or perhaps it won't. Time will tell I suppose.
I think the time and cost is overestimated - if he uses location pack lighting and a backdrop, then very little editing or retouching will be needed. Most shots will simply look good using a common recipe out of camera using a tool like CaptureOne Pro or Lightroom. With professional lighting there's no need to spend any time at all in post; he would if he were an agency, but for what people pay for they'll get perfectly professional quality results. The author is a photojournalist, and as such probably isn't used to work with location lighting, but with available light which is more a matter of luck if you get something decent out of camera. As for printing, either he has a volume deal with a lab or he does his own. Any professional RIP makes it close to zero cost in time, and materials are low to make such small prints. If he wasn't set up before he will be after this. :p
So while I don't think he's making enough to meet payroll on this, the costs are overstated and no way would it take a year.
Finally, if he has an established studio business with commercial clients and wants to branch out, what's the cost of running magazine ads and other promotions? What's the purpose of those ads... to build brand recognition and to get people to try it. Here he gets a guaranteed response ("click through to buy"), lots of exposure, and payroll can be met with the advertising budget.
It's not all THAT crazy.
And not everyone needs an FC to SAN connection that can transfer the equivalent of a non-compressed movie in a few seconds.
Well, yes and no. YOU don't need it, but FC is switched and may be shared with other systems. Like production systems. They might prefer if you transfer at full bandwidth so you spend less time occupying the infrastructure. For just one computer and a bunch of drives in a tray I don't see any need for FC in the first place; eSATA would handle that just fine at a fraction of the cost and complexity.
So exactly where do you buy your Thunderbolt graphics cards?
DisplayPort devices appear like nodes on a Thunderbolt network, so you can theoretically use any DP graphics card or display. Presumably Apple routes the DP output of the graphics card to the TB host switch. Depending on whether they use a stock DP cable you might be able to plug in any card that fits and has an OSX driver and firmware support - the latter if you care about it showing something during boot, but since systems pretty much only reboot on Software Updates anymore this may not really matter. If they use a custom cable you may need an adapter, a special cable, or the card won't work.
Why is so much in the cloud? I've heard it touted in lots of marketing speak, but I've never worked with it.
As someone who has never worked with the cloud (shocking, I know), what are the advantages and disadvantages?
Is it basically just distributed scalable redundant web hosting run by a big company? So you're basically renting to avoid the start-up capital costs of those services and to put them in the hands of specialists, while you focus on your web apps?
Or is it more?
There's a big mix-up of lots of different concepts and ideas here, to the point that the questions you ask are impossible to answer.
- EC2 is a vps-like virtual server provisioning service. You rent a virtual server instance by the hour. APIs exist for you to dynamically add and remove instances as needed. You create an image, then can fire up additional instances as you see fit. Someone like Netflix for instance, can fire up streaming servers during peak hours then shut them down at off hours.
- You can of course set up your own co-lo systems, but it will be provisioned 24/7 and will cost you more since it will be sized for peak capacity, and even during peak most of the servers will be idle much of the time due to random load variance. You can improve peak utilization by setting up your own virtual provisioning. But then you have ops costs, so unless you have a massive operational scale you'll find it cheaper to buy from AWS (or linode, rackspace, etc).
- EBS is a logical volume service. You create a volume and mount it on an EC2 instance. Like with server instances, there are API calls to dynamically create EBS volumes. You can unmount it and move it to a different server in the same datacenter, so you could use them for instance to take backup snapshots or log analysis, or similar, in addition to simply being server storage. Of course you get to build or buy the software to do all these things yourself.
- Server instances belong to groups, and have access controls set up among them. This allows you to create private 'backplane' interconnects, where some things like sql servers are only accessible to instances part of a group.
- EIPs are elastic IPs, which are IPs you lease and can then assign to any of your server instances (usually ingress and point-of-contact servers). You can move them between virtual servers as you like, and obviously would typically map DNS to them. Servers will otherwise get anonymous IP addresses, meaning they get something arbitrarily assigned. They're reachable (if you wish) from the net at large, but aren't well-known points for your service.
- AWS also provides a load distribution service. I've never used this actually; it never seemed to fit right.
- S3 is a cloud service, meaning it has no deterministic ingress and egress. It's used for content distribution: writing is expensive, reading is dirt cheap. Content stored is automatically replicated and de-replicated as needed. You have no idea where it lives, in how many copies, and how it's backed up. SLAs make promises about availability.
- Content distribution is a poster child cloud service example. Not all services will easily fit a cloud model. Many other services that have fit the model (mainly using mapreduce or like) are batch processing based and more about massaging massive amounts of data than interactive end-user services.
- Somewhat simplified, if your service can fit around a key-value store (even a sophisticated one like MongoDB), then it's a candidate for a cloud architecture.
- There are plenty of providers of bits and pieces to do things like server monitoring, cost analysis, and automated/manual server provisioning. In fact, I'm getting into this business myself...
A 'cloud' service is not a hosting service - it's a way to build things, a black-box mindset. There may be a well-defined point of contact (perhaps found via DNS), but beyond that everything is dynamic. The initial contact can redirect, either explicitly or implicitly. It's not like a 'hosting' service where you click a button and get a Joomla host. But it might be a viable way to implement such a hosting service.
21 inches = 1 foot 9 inches. Oops. But exactly the same error happens when people add up strings of decimals and I really don't think there's any difference to speak of.
Can you quickly calculate in your mind: (2 miles) + (321 yards, 1 foot, 5 inches) + (2 yards, 1 foot, 1 inch) + (5 feet, 9 ich) + 6 inch?
In metric ... it is a no brainer.
It's pretty much a no-brainer in imperial as well. You add 6+9+1+5 inches (21 inches = 1 foot 11 inches), 1 + 5 + 1 + 1 feet (8 feet), 2 + 321 yards (323 yards), and 2 miles. So, 2 miles, 323 yards, 8 feet, and 11 inches. No harder to add up than 2km + 321.15m + 2.11m + 0.059m + 0.006m. A paper and pen helps of course.
The wine I drank at a London South Bank restaurant was filled to the 0.75l hash mark.
I hope you meant 7.5cl...
What *really* confuses me about sanitary pipes is that a 3" pipe is 3.5" wide. Errr .... what?
It's intended to fit a 3.5" hole. The inside is standard (so you get smooth joints with other 3.5" pipe), the outside depends on how thick the wall is, which depends on the material it's made from. All you really care about is that the inside can smoothly join with other 3.5" pipe and the fact that it's 3.5" or less in diameter - so it can fit existing holes and conduits, and replace existing 3.5" pipe. If this is all a grand revelation, then I strongly suggest hiring a professional rather than DIY...
If you had taken a quick look at the link you provided, you'd have seen this graph that shows how temperatures rise very quickly after an ice age and then slowly creep down over millennia.
If we are in an interglacial period, climate should be cooling, not warming.
I see about one degree per 10000 years on the upswing. Sustained over a century or more, one degree C per 25 years means it's 25/10025 = 0.25% caused by interglacial warming and 99.75% something else. Or, rounded to the nearest integer, 0% and 100% respectively. Clearly, finding out what this 'something else' is rather than pretend it doesn't exist would seem to be prudent.
The article is wrong; it's 250GB not Gb.
There is a reasonably straight forward technical solution, that could be implemented in a future SSL protocol, to resolve the issue of trust when you already have an account on a site. A host site can add the hash of your password to the symmetric key used after the key exchange, your browser can then do the same on your side. This is essentially using a a shared secret (the hash of your password) as part of the symmetric key.
I like this. In addition, when logging in there's no reason to send the password, when it could be hashed with a random initialization vector. All the browser has to send is proof of knowledge of the password, not the password itself. The password only needs to be sent verbatim when it's changed and during registration. This overcomes a weakness in your proposal, namely that your scheme requires authentication to set up the connection; so it can't be used for the authentication itself. The site also needs to provide a challenge to prevent playbacks, I suppose that could be part of the IV.
Another possibility, to get rid of CAs, is some process of trusted referral. If I'm authenticated with a site I trust, then it can provide me with a token and validator for another site; I send a hash of the token and a random number to the site, which responds with a response and random number. I hash the validator with the random number of compare it to response. If it matches, I consider the site trustworthy and register with it. Once registered, it will be able to prove it's the same site I registered with (as per your suggestion above). This would require the formation of a web of trust. If felt super paranoid I could even get a site's token-validator pair from a couple of randomly selected sources in different countries, just to corroborate.
I've been working with mongo noSQL for a little while now, and it's nice because it's fast and you don't have to de-normalize data that should not have been normalized in the first place.
I totally agree with this. MongoBD is great, but so are RDBMS. They serve different functions. The problem I have is with SQL. It's a language, not a data model or representation. In addition, the server sits at the end of a socket and acts like it's an interactive terminal session, using a human-friendly language, one command at a time. This means for instance that the server has to perform queries in the order issued on any one connection, but there is no guaranteed order or way to state dependencies over multiple connections. As opposed to say having a single connection with a protocol (not some chatty terminal session), asynchronous, based on something as trivial as BSON serialization and JSON-RPC. I'm just tossing these up as simple examples (and ones I'd personally think would be miles ahead). THEN, for maintenance you create an interactive utility that parses a human-friendly query language that could smell and taste like SQL. What amazes me about the effort in the MS researchers' paper is how they try to create another language for non-ACID uses, which I find totally backwards - they should eliminate the language part of RDBMS!
Just look at what happens when a query is made:
1. A textual representation of the query is made, vulnerable to injection attacks or plain errors. Human-readable, as usual, is inherently inefficient.
2. Thread stuffs query object in a queue and blocks waiting on it (on an event object/condition variable that's part of the query)
3. Thread from SQL worker pool wakes up (on queue change event) and picks up request
4. SQL pool thread sends text to DB server and blocks waiting for a response
5. The process reverse on the server via a reactor pattern
6. Server sends back human-friendly reply
7. SQL pool thread wakes up and picks up response, and parses it (it has to look for errors)
8. SQL pool thread tacks response to query object, signals a change to it, and goes to pick up the next query or sleep
9. Application thread wakes up when query is signaled
10. Application thread parses the reply (second time, because it knows what the query is which the SQL pool thread doesn't, unless it were to parse the query)
Compare this to:
1. Application builds data representation of query, either by building a simple tree from scratch, or using an algorithmic tree transform on a more complex set of data. If data isn't natively in BSON or whatever is used, then it's transcribed.
2. Application thread grabs lock and adds RPC envelope to query, registers the RPC ID, writes RPC object to server socket, releases lock
3. Application thread waits for query to complete, by volunteering to service the reactor (if no other thread already does)
4. A response comes; the RPC ID of the original call is looked up, the query object retrieved, the response envelope removed, and the response tacked onto the query
5. The calling thread is woken up. If there's only one thread making queries and the reactor doesn't have a dedicated service thread (or pool), then this is the same thread that waited in select/poll/epoll/kevent(), and it's simply returning.
6. Data is deserialized, if needed.
If you're a programmer you can immediately see why SQL is such a massive complexity on top of what is really a pretty simple problem with a simple solution. The number of connection to juggle, service pools, blocks/unblocks, context switches, parsing and serialization spread all over, poor layering, fits poorly with asynchronous applications, etc etc. In fact, there's actually nothing wrong with SQL per se, the problem is that it's not needed in the first place any more than a program should call a subroutine by emitting text for it to substitute parameters, then compile and run it! That doesn't mean there's anything wrong with compilers!
1) You start out observing something the current theory can't explain.
2) Come up with a new theory that accurately predicts all experimental results so far, the newly observed effect, and that also predicts something new that has not been tested yet.
3) Test the new thing that the new theory predicted. If you do observe the new effect, it lends credence to the theory.
Except, of course, it's a hypothesis until 3 has been repeated a few times by different people; in particular by critics looking to disprove it. After it stand up to this scrutiny and organized efforts to disprove it actually fail, in the process proving it, it becomes a theory. Theory means only theologists will argue against it. But in vernacular use, theory = hypothesis.
No, the story is far from out as to what the hell is going on, but the levels have reached well beyond what we were not worry about "because it isn't this high". Let me post once again the link to xkcd's excellent map of radiation levels. http://xkcd.com/radiation/
This is really only relevant to full-body irradiation. The energy goes up with the inverse square of the distance to emitter - for a cosmic source this is irrelevant. But for a tiny radioactive dust speck it makes a big difference. Inhale it and it gets stuck in your lungs. The tissue immediately surrounding it (at microscopic distances) gets nuked and cell death ensues. In effect, you get a tiny lesion. Normally, when you get radiation burns you remove yourself from the source and heal up. But with the inhaled dust speck it sits there, with no chance for reprieve; when your body responds with inflammation and fibroblasts it gets continuously nuked. Scarring builds up. It's like you pick a scab year after year and won't let it heal. Eventually the lesion gets chronic and cancerous and begins to spread. You really don't want to seed your organs with radioactive isotopes. This is also why Potassium (which is radioactive) is harmless - it's water soluble and gets flushed out. Iodine collects in the thyroid, strontium in bones (it's a calcium analog).
The Sievert scale approximates physical injury - but it only works for large-area irradiation, not long-term exposure at microscopic distances. In this context, even a dental x-ray is immensely broad-area and assumes a distant emitter. Alpha radiation is weighted to adjust for epidermal protection. For higher intensities it also assumes brief exposures and that the body is given an opportunity to heal.
You have to wonder who actually ordered the gas not to be vented into the atmosphere.
How are you going to vent it without power? Open a window?
The bad faith isn't in losing the laptop, it's in the BP policy allowing workers to have this information on laptops that can be lost.
At least without crypto to protect it. I keep a lot of sensitive paperwork (contracts, etc) on my laptop, but it goes in an encrypted file system that's only mounted as needed, then unmounted.
Emacs runs just fine natively on OS X. I build my own, but there are lots of binary packages. I do a fair amount of python code; works fine, too. HOWEVER, for projects that involve databases, Apache, custom Apache modules, mod_python, and OS specific optimizations I use a VM. The reason isn't just one of compatibility or applicability, but of sane containment. I don't want all this stuff on my everyday system; I WANT it contained in a VM. When I suspend the VM I suspend this entire assortment of servers. If I screw up the configuration I can easily roll it back to a previous snapshot. The great applicability - meaning I can run a kernel and system configured exactly as the target server I plan to deploy on - is icing, though obviously quite important as focus switches from functional to performance and stability, and to fixing system-specific issues or crafting package install scripts. Usually one VM for development and one for testing - the latter checks that there are no dependencies on having dev tools installed (which a deployment server won't). For different projects you'll then obviously set up different VMs, so they won't step on each other.
Um. No. Many modern libraries or "frameworks" (newfangled word for library) are OO. Most OSes remain written in classic system programming languages like C and assembly language. In fact, most frameworks start as object oriented wrappers for certain OS calls and cruft up from there.
A framework is a collection of libraries and other resources, like daemons and agents. The C runtime (including crt0.s etc) can be said to be a framework. In fact, "runtime" is closer than "library". You could say, for instance, that the is a Core "runtime", a UI gadget "runtime", a Windowing "runtime", a "video rendering" runtime, etc - but it's a bit weird conceptually to have multiple runtimes. Enter the term Framework. In older days we used to call these "layers" and similar, but Framework is more general and doesn't paint you in a corner where you're forced into layering violations just to get something to work. A Framework may also include daemons, like a UI manager, SNMP agent, or such.
That's very interesting. To elaborate on your post, I think it would be very useful to have a native python compiler backend that's fed an RTL-like intermediate structure. Out comes a blob of machine code with a module interface. It doesn't have to be quite as low level as GCC RTL, but could be something closer to C++ with typing, function names, variable names, etc, so closer to the front end. (It could be expanded to GCC-like RTL in a first step of course.) Hooks could be used to apply application-specific optimizations. It should be quite possible to use gcc as a starting point for this.
Yeah. The phrase "trade school" shouldn't be seen as a bad thing. At the end of the day it comes down to egos. People want to be seen as smart. If someone went to a trade school, and another to university, people will think the university kid is smarter.
The purpose of trade schools is to teach a practical vocational skill to someone who isn't intellectually top shelf but who can still perform many jobs just fine. An auto technician/mechanic would be a good example; they can diagnose and fix most problems. But you don't expect them to be able to design auto parts; designing an engine is a whole different ballgame than fixing one. Automotive engineering is not a vocational trade.