|
Fingerprint-reading software preinstalled on laptops sold by Dell, Sony, and at least 14 other PC makers contains a serious weakness that makes it trivial for hackers with physical control of the machine to quickly recover account passwords, security researchers said. Light-fingered hackers make light of your fingers.
|
|
|
|
|
Nokia today announced its new flagship Windows Phone 8, the Lumia 920, with a powerful PureView camera as the centerpiece. The Nokia Lumia 920 has a 4.5-inch curved glass display with a resolution of 1280 x 768, a 1.5 GHz dual-core Snapdragon S4 processor, 1GB of RAM, and 32GB of storage. How do you think this measures up to Android and iPhone alternatives?
|
|
|
|
|
“In federal rules tests, there are just two dummies tested,” Reed reveals. “And manufacturers are using computer simulations that are effective in predicting what will happen in a dummy test.” But what about real humans? What about the 75-year-old man with soft ribs and a curved back, whose short-sightedness causes him to sit close to the dash? ...state-of-the-art computational models are tweaking airbags, seatbelt and vehicle designs to accommodate him and the rest of the world’s drivers. You have crashed. Game over. Ready driver one?
|
|
|
|
|
We should all be pretty well aware at this point that the robot apocalypse (or "robopocalypse," if you will) is on its way. Our most gifted storytellers have been warning us about it for years, from the legend of the golem to James Cameron's Skynet. In their latest volley against an unsuspecting human race, our metallic overlords-to-be have conscripted MIT researcher Kate Darling to draft a new research paper that suggests humans grant rights to robots. According to Darling, robots don't need rights on par with humans (yet), but due to the emotional connections humans can create with them, we may find it beneficial to ascribe them similar rights to our pets. This is the voice of world control. I bring you peace.
|
|
|
|
|
So because some people act like tards around robots we should all treat them the way the idiots do? 
MIT's standards are slipping these days. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Windows Phone 8 looks great. Its features and capabilities are far better than Windows Phone 7 (and you know I already think WP7 was a “superior” product). It has a well-designed look and feel that enables it to stand out. It has all the features the competition has and also some innovative capabilities they don’t. Will Windows Phone 8 devices sell in sufficiently large numbers to make Microsoft a strong force in the smartphone space and keep Nokia in business? I don’t know. A human salesperson, acting 1:1 with a customer is an extremely powerful force.
|
|
|
|
|
In the "it's cheaper to run Linux than Windows" camp, I give you the Linux Ultrabook[^]. Ouch, that has to smart.
|
|
|
|
|
|
So am I getting something better than 1080p on a phone that is HD+, Don't think so.
|
|
|
|
|
Resolution is not all as I think you know. It's about the smothness, frame rate, bruightness and more much more.
So yeah, in my opinion, the 920+ has better video recording than most of the 1080p ones.
I'm not saying it's the best cause I can't really pronounce since I havent tried one. But from the tech reviews it's pretty good.
All the best,
Dan
|
|
|
|
|
True. I actually am impressed that some of the new laptop manufactures are putting 900 line display in thier laptops, unlike Dell, etc. I know that on laptops in the past I could not play 1080 videos at all.
|
|
|
|
|
|
Regarding this: Namespaces are dead
Ok, so this came to me in todays newsletter.
How is this "Developer news"?
This represents noob thoughts by an unexperienced programmer (if at all).
I wonder if The Insider Newsletter's editor even reads the articles before choosing them for the NEWSletter.
|
|
|
|
|
the.komplikator@gmail.com wrote: How is this "Developer news"?
The newsletter often contains blog entries of people's opinions of how technology is changing. This article is no different.
the.komplikator@gmail.com wrote: This represents noob thoughts by an unexperienced programmer (if at all).
And what makes your opinion so much more valuable? Just because you don't like his opinion you sink to insulting the guy?
|
|
|
|
|
This wasn't about the article at all. This was about the editor choosing that article as "news".
"News" is something that actually happened, or something that is really going on. Like "Microsoft threw away C#".
The article was a blog entry about author's thoughts of how things could be. That cannot be news.
|
|
|
|
|
Last I checked general news sources also contain things like political opinion pieces. I'd say this is fairly equivalent.
|
|
|
|
|
Should this even be posted in the News Section?
Could someone please move it to the Lounge (at least), or to the Oblivion (at best)?
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
|
it IS a spam dedicated email 
|
|
|
|
|
the.komplikator@gmail.com wrote: This represents noob thoughts by an unexperienced programmer (if at all).
You really don't know who he is do you?? You might want to do a little research. You may find out that he's got far more experience than you think, possibly even putting YOU to shame.
And I happen to think he's right. Namespaces ARE an obsolete concept. I find that future development is going to rely more and more heavily on package managers of more than one type to add organized functionality to dev environments and projects.
For example, in the past, IDEs like Visual Studio are generic, allowing you to build projects of all types, but treating each project type more or less the same, with monolithic designers built into the IDE. This approach limits your ability to write code because you're stuck using the built in capabilities that don't extend beyond their base functionality.
But, what if you could completely customize your development environment specifically for the project you're working on? Swapping out designers, tools, and frameworks for different sets and different capabilities on a project-by-project basis?
This treats the IDE as part of the project, instead of having the IDE being a generic tool that just works on the project.
THAT's where developement is headed and what Bertrand is talking about. Instead of shipping large monolithic frameworks that are trying to be all encompassing for all kinds of project types, the notion that something like the .NET Framework should be broken up into MUCH smaller frameworks and added into projects on an as-required basis as packages. This has the effect of eliminating, or at the very least, greatly reducing the need for namespaces.
|
|
|
|
|
Well, first of all, that's NOT NEWS, as I pointed out.
But, regarding your topic...
Microsoft .NET Framework is an all-in-one generic framework. It encompasses all functionality you could ever need on a computer and even further. Ever. No matter what kind of project you are making.
.Net already IS broken down to little pieces. They are called assemblies. U know "add reference..."? That is pretty much what you do when you "add [smaller framework] into projects on an as-required basis as packages". And then when you build your project, only those assemblies are used and deployed.
So, now you have an enormous bunch of code deployed to you by default. Imagine if there were no namespaces. Then, get some source code that was made by someone else. And then build some reusable library. Hey, that's a bunch of code that has no programmatic organization. Wow! That's useful.
This looks like some people (and I'm not pointing fingers now!) are pushing some obviously rather unpolished technologies and reinventing the wheel, instead of using whatever's already at hand. Or at least accepting years and years of theoretical and practical research that's been put into constructing useful concepts.
|
|
|
|
|
the.komplikator@gmail.com wrote: Microsoft .NET Framework is an all-in-one generic framework. It encompasses all
functionality you could ever need on a computer and even further. Ever. No
matter what kind of project you are making.
Sorry to break it to you, but that's just wrong. For instance, I want to swap monitors with a WPF application at runtime - well, I've got to drop down to the Win32 API. Oh wait, I also want to use GIS functionality, well I have to go third party or roll my own. Ah, how about AJAX calls from the browser? Oh wait, that's JavaScript.
The point that was being made in the article is that there are alternatives. Namespaces are a useful feature for a framework such as .NET, but we are where we are with .NET because of legacy code. How different would it be if it was written now?
|
|
|
|
|
Yes, but .Net still has a way for you to do whatever you want. Many language-frameworks exist that do not let you do that at all. Sometimes you realize that a lot too late.
Pete O'Hanlon wrote: The point that was being made in the article is that there are alternatives. Namespaces are a useful feature for a framework such as .NET, but we are where we are with .NET because of legacy code. How different would it be if it was written now?
I don't think it would be much different. Framework itself encompasses some basic computer/OS functionality. It could be upgraded, but not much different.
On the other side, C#, VB and F# are languages that define how we can use that functionality. Microsoft keeps upgrading both the framework and languages with new features. They are a product of over 40 years of object oriented programming theory and practice. Namespaces included 
Sure, it COULD be different, but wouldn't that then simply be a new language altogether?
|
|
|
|
|
the.komplikator@gmail.com wrote: Microsoft .NET Framework is an all-in-one generic framework. It encompasses all
functionality you could ever need on a computer and even further. Ever. No
matter what kind of project you are making.
Uhh, where in the Hell did you get THAT from?? No, it doesn't encompass everything. It tries to supply a lot of functionality that is common to all types of projects, but it does not cover everything.
the.komplikator@gmail.com wrote: .Net already IS broken down to little pieces. They are called assemblies
Yes they are, but do you need to deply ALL the assemblies in the .NET Framework with every project type?? Is every project going to use every assembly in the .NET Framework?? No. Namespaces help keep all the assemblies oraganized into large related collections, most decending from the System or Microsoft namespaces. That's completely unneccessary. The root namespace for a collection of functionality should be the assembly itself, not the entire framework. In most cases, that greatly reduces the height of the namespace tree to one or two levels.
the.komplikator@gmail.com wrote: So, now you have an enormous bunch of code deployed to you by default. Imagine
if there were no namespaces. Then, get some source code that was made by someone
else. And then build some reusable library. Hey, that's a bunch of code that has
no programmatic organization. Wow! That's useful.
Actually, we already have examples of this. Ever hear of the Entity Framework? NUnit?Each has a very small namespace tree. Is it REALLY required?? No. Today, namespaces only exist to avoid name collisions, not really for functionality or organizational reasons. What are the chances a namespace tree in a library is going to have two classes with the same name?? Virtually zero.
Yes, namespaces still offer functionality organization, but is it really necessary to write code?? No, it's not. I dare you to give me a single compelling reason from a developers perspective to justify the existance of namespaces in a library. Sure, from the library developers point of view, it's nice because you can keep your functionality seperated and organized for that developer.
But, from the consuming developers point of view, it's more crap I have to type at the top of my code files to get VS to do the name resolution for me so I don't have to type out complete namespace paths for every frickin' object type. I just want to reference EntityFramework.dll and that's it. All the classes in that .DLL should now available to me under a single "namespace" called "EntityFramework". I don't want a 3 or 4 level deep tree.
On top of that, now I just have to deploy EntityFramework.dll to get the functionality instead of having it baked into a 300MB .NET Framework I have to deploy.
the.komplikator@gmail.com wrote: This looks like some people (and I'm not pointing fingers now!) are pushing some
obviously rather unpolished technologies and reinventing the wheel
What?! EVERY technology and paradigm at v1.0 is unpolished! Do you think the HTTP 1.0 spec was a chrome plated masterpiece when it was released?? Hell no! Everything, from specifications to implementations to paradigms are all unpolished trial-and-error works at v1.0. Everything evolves over time with use to see what works and what doesn't.
Having no namespaces is just another example of a "Hey, try this and see what happens" idea.
|
|
|
|
|
Dave Kreskowiak wrote: Uhh, where in the Hell did you get THAT from?? No, it doesn't encompass everything. It tries to supply a lot of functionality that is common to all types of projects, but it does not cover everything.
Yes, it doesn't provide neural network capabilities, does it? Well, Microsoft's task was to create framework that exposes OS to the developer, not to read his/her thoughts. Custom libraries do that.
Dave Kreskowiak wrote: That's completely unneccessary. The root namespace for a collection of functionality should be the assembly itself, not the entire framework. In most cases, that greatly reduces the height of the namespace tree to one or two levels.
Each namespace system has two dimensions: 1) where is the "framework" code located (framework namespace) and 2) where is your code located (your class namespace). Therefore, if you really feel like your code should access assembly code without "using" directive, you could place your code into the same namespace in which assembly code resides. You could, but you shouldn't.
Dave Kreskowiak wrote: Actually, we already have examples of this. Ever hear of the Entity Framework? NUnit?Each has a very small namespace tree. Is it REALLY required?? No. Today, namespaces only exist to avoid name collisions, not really for functionality or organizational reasons. What are the chances a namespace tree in a library is going to have two classes with the same name?? Virtually zero.
Well, as far as I remember, Entity framework has a small namespace tree because most of it's functionality was implemented using extension methods and such evil trickery
Dave Kreskowiak wrote: Yes, namespaces still offer functionality organization, but is it really necessary to write code?? No, it's not. I dare you to give me a single compelling reason from a developers perspective to justify the existance of namespaces in a library. Sure, from the library developers point of view, it's nice because you can keep your functionality seperated and organized for that developer.
Well, if you develop a project that has similar functionality on different places, you would probably want some code reusability. Whenever "similar" is not similar enough, you want to change the reused code. The proper way of code reusability (by teachings of classical OOP) is to inherit the code, and then change inherited behaviour. That means you will have to either 1) change the name of your derived class so it doesn't conflict with base class' name, or 2) put it in another namespace. Another example is when on one place in same project you have "Person" entity that contains data and maybe some logic, but on another place you also want a "Person" entity with different data, and a different logic. Therefore, you organize your project into namespaces, so one namespace doesn't "bother" you when you're working on another.
Dave Kreskowiak wrote: On top of that, now I just have to deploy EntityFramework.dll to get the functionality instead of having it baked into a 300MB .NET Framework I have to deploy.
Yes, but maybe you don't have to. It is most likely already there. In that case you have to deploy only custom libraries.
Whatever framework you use, you will have to deploy it, because not a single framework is deployed with OS (except .Net in some cases).
Dave Kreskowiak wrote: What?! EVERY technology and paradigm at v1.0 is unpolished! Do you think the HTTP 1.0 spec was a chrome plated masterpiece when it was released?? Hell no! Everything, from specifications to implementations to paradigms are all unpolished trial-and-error works at v1.0. Everything evolves over time with use to see what works and what doesn't.
HTTP 1.0 was practically first-of-its-kind. Therefore it wasn't reinventing the wheel. Namespaces in OOP exist for over 40 years, and all of a sudden they're obsolete and unnecessary? Namespaces are part of OOP, which has been very well tested, and trillion times proven useful. So it's useless if most of the time people don't use it?
modified 6-Sep-12 3:56am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
