|
And for the sense of humour (can I borrow some?) +5 here, +4 on previous post - since I agree with the sentiment.
Ah! Perhaps I will watch that movie about 'people' after all..
Make it work. Then do it better - Andrei Straut
|
|
|
|
|
Whilst our cluster size isn't really comparable with the largest Hadoop deployments in the medical or physics fields, at just under 1 PetaByte and doubling in size every 3 months, it's probably a lot larger than the average amount of data most companies have to deal with. Since the announcement of our closed alpha, the demand for historical Twitter access has been huge, so we knew early on that we couldn't release a service that would collapse with just a couple of queries or that took forever to process data: if you start a query now, you don't want results in 15 days. Because the data keeps growing and growing and...
|
|
|
|
|
Advertisers love the AR because it involves users having to physically interact with a product: pick up a cereal box and you are 3/4 of the way to buying it. For most applications however, AR is still a gimmick. Having to wave your phone around at an object to play a game is a huge hassle. A compelling business case hasn’t been made yet–this is evidenced by the fact that most AR conferences feel more like amateur science fairs than bustling hives of commerce. AR Is Still A Gimmick
|
|
|
|
|
Distribution was the key idea of Public Radio Exchange. The big stations only had 24 hours a day to broadcast, just like the smaller-market stations. Podcasting overturned that idea. With the Internet there is no concept of a 24-hour broadcast day. You can upload as many hours of MP3s as you like, and if there are people who care, you will get listened to. Eventually that battle was settled and today PRX is a thriving venture, distributing podcasts of course. Podcasting is about freedom, just like blogging.
|
|
|
|
|
Nowadays, we take Ethernet for granted. We plug a cable jack in the wall or into a switch and we get the network. What's to think about? But it didn't start that way. In the 60s and 70s, networks were ad hoc hodgepodges of technologies with little rhyme and less reason. But, then Robert “Bob” Metcalfe was asked to create a local area network (LAN) for Xerox's Palo Alto Research Center (PARC). His creation, Ethernet, changed everything. Are you sure it's plugged in?
|
|
|
|
|
"(At least among networking geeks, the people who could name the seven layers of TCP/IP off the top of their head. Our sort of folks, that is.)"
Okay, name those seven layers of TCP/IP. No matter what kind of a geek you are, you can't!
IBM's Systems Network Architecture had 7 layers. ISO uses a 7-layer protocol.
TCP/IP uses 4 layers.
|
|
|
|
|
The Internet may be hurtling toward collapse under the strain of too much traffic. But PARC research fellow Van Jacobson thinks he knows how to fix it. He’s done it before. Back in the mid-1980s, when the Internet was seeing its first modest surge in usage, Jacobson noticed that data packets were piling up on the message routers of the day, like cars waiting for cross-traffic to clear before entering an intersection. Working with fellow Berkeley computer science instructor Mike Karels, he came up with a small change to the Transmission Control Protocol (TCP) that, in essence, allowed packets to ease into the intersections gradually, curing the congestion. Replacing “Where Is It?” with “Who Wants It?”
|
|
|
|
|
A lot of press has been released this week surrounding the cracking of MS-CHAPv2 authentication protocol at Defcon. All of these articles contain ambiguous and vague references to this hack affecting Wi-Fi networks running WPA2 security. Some articles even call for an end to the use of WPA2 authentication protocols such as PEAP that leverage MS-CHAPv2. But they fail to paint a true and accurate picture of the situation and the impact to Wi-Fi networks. I think this is misleading, and that any recommendations to stop using PEAP are flat-out wrong! No, and we'll explain why.
|
|
|
|
|
HTTP has been a longtime abuser of TCP and the Internet. It uses mountains of different TCP sessions that are often only a few packets long. This triggers lots of overhead and results in common stalling due to bad interaction with the way TCP was envisioned to be deployed. The situation is so bad that over 2/3rds of all TCP packet losses are repaired via the slowest possible mechanism (timer expiration), and more than 1 in 20 transactions experience a loss event. That's a sign that TCP interactions are the bottleneck in web scalability. The period of stagnant protocols is ending.
|
|
|
|
|
|
|
Most users don't need it. But developers certainly do, some programs do not have a UI of any sort, graphical or otherwise, beyond command line arguments, and it may not make sense to add one (like most compilers), so developers and power users need a way to interact with them (creating and editing a shortcut is not an acceptable solution).
|
|
|
|
|
It shouldn't, and I hope it doesn't, but I expect to give Win8 a pass anyway so it doesn't really matter to me.
I currently use Win7 and I spend most of my day at the command line because I write mostly console apps and backend code.
One of the things that struck me as odd about the Macintosh (80s, 90s) was that it didn't seem to have a command line and I wondered how anyone could do any serious development on it. I understand that the more recent Unix-based Mac OS does have a command line, so I hope that shows how important the command line is.
Personally, I still want an OS that will boot to and be usable at the command line without loading the GUI.
|
|
|
|
|
PIEBALDconsult wrote: Personally, I still want an OS that will boot to and be usable at the command line without loading the GUI.
You can configure Linux to do that I think, and switching between multiple text and GUI shells is easy (something like Ctrl+Alt+F[number of the shell], I don't remember exactly if those are the correct modifier keys). Every Linux based OS I've used had at least two (maybe four?) text-only shell sessions available by default, and usually a couple GUI shells too. You don't even need to log off/lock your session/etc. to switch users using that.
|
|
|
|
|
For most linux installs I do here at work and even at home I do not even install the GUI at all. It's certainly not needed for a fileserver that is not normally used at the console. > 99% of the time I do administration via a ssh session usually from windows putty and use screen to have many virtual console windows inside a single ssh connection.
John
modified 8-Aug-12 10:29am.
|
|
|
|
|
I know a lot of developers who do already, and a lot who don't.
*shrug*
|
|
|
|
|
Considerable efforts have been invested by many different organizations in the past on the development of coding standards for the C programming language. The intent of this standard is not to duplicate the earlier work but to collect the best available insights in a
form that can help us improve the safety and reliability of our code. By conforming to a single institutional standard, rather than maintaining a multitude of project and mission specific standards, we can achieve greater consistency of code quality at JPL. Want to write code for spaceships? Start here.
|
|
|
|
|
Rule 16 (use of assertions)
Assertions shall be used to perform basic sanity checks throughout the code. All functions of more than 10 lines should have at least one assertion.
|
|
|
|
|
For what their doing, it's probably better to crash the program than to use incorrect values in and crash the hardware...literally.
|
|
|
|
|
oh sure.
but what if you can't find something to assert on in those ten lines?
|
|
|
|
|
That's why it says "should" not "shall".
|
|
|
|
|
right. but you should have one in there. so you'll be searching for a place to put one.
seems like a distraction.
|
|
|
|
|
Chris Losinger wrote:
but what if you can't find something to assert on in those ten lines?
You split the function. Especially in C, ten lines is about as long as a function should be. Anything longer already looks like a bug nursery.
OTOH, I'm not so sure about assertions in production code in C. Occasionally a function might not be able to do its work, but some function up the call stack might be able to recover sanely - and this might be desirable.
Therefore I prefer a different approach: always check your input, always return an int error code, to let the caller know whether the call completed successfully, and return computation results in a preallocated buffer. This is in fact the way most C code is written. And enforce a rule that return values should always be checked.
|
|
|
|
|
"Do not use goto, setjmp or longjmp."
Bah. You're no fun anymore. 
/ravi
|
|
|
|
|
Now that Visual Studio 2012 is done, we’re busy figuring out what we should do next. For Web optimization, there are a few key scenarios that we know we want to support moving forward. There are also a whole bunch of other scenarios that we’ve either heard from different people or come up with during brainstorming. Here are some of our ideas. What do you want to see in ASP.NET Web Optimization?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
