You couldn't be more right about the collective skills of Windows "admins". Many in my experience earned a piece of paper after completing some joke course at a two-week correspondance school. However, being a programmer who directly deals with these people has inspired me to write the point and click tools myself instead of trying to hold their hand through the simplest tasks. This scripting environment looks like a very nice fit for accomplishing that task. Heck, it's designed to be the foundation for the MMC panels - the familiar stomping ground of the "certifiable".
In the past, I've always had to resort to some Frankenstein WSH + script + binaries that do all the crap WSH can't do and it's a damn mess, but still a time saver over telling numbskull after numbskull how to do their job.
The sad fact is Microsoft wants to further the notion that any chump off the street can administer your network (which really seems at odds with their insistence on heaping mounds and mounds of arcane and disorganized crap onto everything they produce). Oftentimes, the HR interviewers at these places are impressed by candidates who lack any and all skill, and people like me are left to deal with them, and that is the likely case study in play here.
Full Screen map. MSN Virtual Earth provides this and it is better than having so much wasted screen space.
Ability to label places on the map. For driving directions or city tour, etc., it is often helpful to have a number key of locations labeled. For example, my wife was headed downtown and wanted me to point out the parking garages, gas stations, various landmarks, etc. I had to crack a screenshot open in a graphics editor to make the changes (however the result was very helpful to my wife).
Ability to select sections of the satellite image to have added to a road map. Sometimes, less is more, and road maps are confusing if they contain too much detail (and the hybrid is distractingly detailed for some locations). Many people prefer directions that include identifiable landmarks and if you could add the major buildings and features and leave the rest off or faded out... well, that would be useful.
Love to see Google promote this site. I haven't used mapquest in quite some time.
A couple of folks shave hit on the possibility of using a peer-review system. I think this is a fine idea; however, it seems to me that it could be extended a bit to offer this "expert-friendly" culture Larry indicates.
My pie in the sky idea'r is to develop a genetic algorithm that's aimed at finding the optimal formula for identifying the smarties.
The basic idea is to have a ranking system (a score for each contributer's level of repute that entitles them to specialness). Here's a five-second brainstorm on some possible inputs...
peer moderation (weighted by the reputation of the peer)
academic review ranking (invite some well-known academic-types to participate as a helpful indicator, not as a dictatorial force)
examine the activity of the articles for some other subtle indicators (do the submitted articles get extended? revised? deleted?)
To evolve the formula, one could provide recombination of the rules based on...
a survey of how well the ranking formula is working overall.
feedback on the importance of each of the current inputs
a brainstorming mechanism that allows contributers to submit new input ideas (subject the new ideas to a ranking system and make a decision whether or not these could be added to the ranking formula, which could also be subject to an open survey)
When conducting a survey, you could weigh the responses based on reputation, and you could subject that weighting factor to survey as well. I think I've done enough babbling for now...
The goal would be that if you're trollish enough, you could be placed into exile, made to suffer review on your edits, or whatever. If you're wise enough, you could be asked to perform academic reviews, be eligible to win a free coffee mug, or some other token of superiority.
I know, the genetic algorithm thing probably isn't all that necessary, and there's always a chance it could unravel itself, but it seems to me like it would be a very interesting experiment with such a large population of contributers... Final thought: I think some incentive to be a good wiki-citizen would be a wise addition, and it doesn't need to conflict with the open nature of the project IMHO.
I'd have to say that Paint.Net is pretty nice. It has an intuitive interface, and support for the most-used functions in a general picture editor.
Performance was not a problem on my PC. Some have reported it is on theirs. I am running a P4 3.2 GHz HT w/512 MB RAM.:)
Now to the constructive criticism...
Tooltips came up under the tools in the toolbox. So, I couldn't see them, and I had to go to the help file to find out what some of the non-standard tools did.
Transparent windows are cute enough, but flicker annoyingly when you drag a selection beneath them.
Better fill options would be nice (like a gradient fill perhaps - I know GDI+ contains support for this).
Huge memory management problems. After playing with an image for about 5 minutes, my Task Manager reported 160 MB memory in use for PaintDotNet. This figure seemingly rose with every operation, and almost never went down. Further, at one point, pencil and brush drawing stopped functioning entirely.
The memory problem is a big one. I'm guessing that the history list is largely responsible for the offense, and that some disk cacheing could remedy the problems. Garbage collection isn't a license to grab all the RAM on my PC.
Anyway, a good free program all-in-all. A bit of a heavyweight to be a Paint replacement though.
A business that outsources core competencies is headed in the wrong direction. I happen to work for a company that has experimented with outsourcing (both inside the US and offshore), and the process works for some software efforts, but certainly not for the core businesses and domain-specific developments.
If a company outsources its core businesses, it effectively reduces itself to a distributer.
I know it sounds like GNU-style recursion and a bit silly at first, but we've used this and users applaud it, from rookies and gurus.
Simply put, make the default set of options the ones that are most commonly used and easiest for beginners to understand. Add in an editor for "Experience Level" or something like that, and have that editor provide a slider (or whatever) that, when set, will gradually reveal more or less detail in the options presented to the user.
The result: new users aren't overwhelmed with settings they don't understand and probably shouldn't mess with, and advanced users can set the experience level once, and forever have every configurable setting at their fingertips.
Excellent point. We write Neurological device software, and projects past have overlooked the all-important facet of applications and domain experience on the enginerring team. Knowledge of the user's situation and of the science behind the solutions is absolutely critical in technically-challenging efforts.
Innovative solutions are generally harvested from people who truly understand the work flow of the users.
Hmm, good question. I've only heard rumors about the plans for drivers. Once I heard the driver spec was changing but not finished, then I heard it wouldn't change. I think its safe to say that Microsoft is going to try to keep existing HW partners happy, whatever becomes of the registry, or wherever its current functions land.
I'd expect emulated support for the registry (along with the emulated Win32 API), but the windows system itself will stow object info to the Global Assembly Cache. Configuration data will be moved to XML stores. Apps are encouraged to load config data from within the same folder as the assembly. After a spell, the registry will be deprecated (once major players have made the migration).
Still, I can think of a number of legitimate reasons for such an interpreter to be written that includes cases where you'd want to allow it access to file systems and networks and so forth (cross-platform network utilities in Perl, for example). Of course, you'd be taking your security risks by your own hand in that case.
When a user installs a.NET exe, do they select access security during the install? I wouldn't guess that the default access level would sandbox every executable (though admittedly I don't know). Unless such a decision is forced during install, many users would fail to secure their machines (as is the case today).
Aside, much of the fear of Palladium in this forum has centered around.NET crushing the home-brew app writer. Circumvention may be the wrong term here, but I believe this could be a reasonable way to allow home-brew apps to continue without mandating certs.
The underlaying rules behind evolution are testible, and have been proven as well as any scientific fact can be (see the Problem of Induction in any philosophy textbook), which is why evolutionary modeling techniques are used in any field that requires predictions about complex molecules. This includes chemical engineering, medical research, and even computer software design.
Interesting examples. All fields of human creation.
Not to split heirs, but the Theory of Evolution is in fact a theory, not a fact (by the scientific definition of the words). Of course, there really aren't scientific facts, just laws, and any good Slashdot reader knows full well even laws are subject to interpretation by those who wouldn't use IANAL.
Anyway, you've laid down some good arguments/information, but this thread is missing the bones of contention against evolution: that large gaps in the evolutionary record fail to prove macro-evolution into law-dom, despite demonstrable micro-evolutionary experiments. Given that lost records may forever be lost, a fair part of evolutionary dogma amounts to speculation, and shouldn't automatically be lumped into tested and demonstrated evolutionary events as "part of the facts".
I likely fall into that group of consensus believers you mention, because I tend to accept macro-evolution as a better explanation of our world than divine creation, though I simply cannot ignore the "Argument by Design" (also in any philosophy textbook). My personal belief is that the story of creation was actually the first draft of "The Evolution of Man", albeit recorded before the Beagle was constructed and at a time when unanswerable questions were frequently punted to God (not unlike today, really).
If there aren't natural rules, then the scientific method is bogus, because tomorrow the universe could change into something entirely not like it is today. If there are such rules, how could they arise from randomness? Can something ordered arise from something random? That's my thinking anyway...
I have to ask (because I don't know), are their insurmountable technical barriers that would prevent compiling both Java and C# to the same bytecode?
The author calls for an open Java VM (which is a very good call IMHO), the natural assumption is that the runtime would execute Java bytecode, as it should. Is there a reason why C# couldn't be compiled to Java bytecode, and if so, then could extensions be added to accomodate non-Java languages?
I agree that Linux needs a solid front, but many of the issues raised speak to factions that want their technology to reign supreme on Linux. Why not have a runtime that runs all languages and let the coders decide which to use?
Aside, excellent insight into the purpose of XAML. You've got to realize that Internet Explorer Longhorn Edition is going to fully support all of the vector-based rendering APIs available to XAML's GDI/GDI+ predecessor. This means a full-featured GUI that can use a rich set of Microsoft's controls will be able to execute from inside the web browser using the same code you'd write for a local application. This is a huge deal, and whether it be XUL or something else entirely, Linux needs a equivalent alternative.
Ok, so I think the writing on the wall reads, "M$ will be requiring code to run through the.NET CLR", if it is to run on Windows.
So, in response, we have C compiling to bytecode. But, Longhorn will require bytecode assemblies to be signed; I suppose that could be built into the compiler as well (else wouldn't we lose portability?)
I was thinking along these lines a while back, and thought to myself, "What's to stop somebody from writing an interpreter for any language (I was thinking scripting at the time) that will run as a.NET app? [Ruby was on my mind]
What's the impact of doing this, you ask? Well, if the interpreter itself is the signed certificate-backed secure executable, then any little scriptlet or homebrew app could be run without being digitally signed!
To me that allows a fairly obvious circumvention of Palladium, and "trustworthy computing" is out the door.
I'm not against CSS, I find it essential for styling, really (inline styles hamper the readability of the HTML). CSS2, on the other hand, has some nice features that I can almost never use for the reasons I previously stated.
Usually with PHP, I'll separate code from HTML by using HTML files with inline PHP:
or I'll call functions from imported files, etc. Though its not really relevant, I'm also starting to like XSLT for XML DB stuff. The XSLT then contains the full html representation, and the PHP is pure code.
So, I like CSS, don't get me wrong, but I usually find myself using tables for formatting.
This type of solution doesn't really fix the problem that the CSS2 W3C standards aren't correctly supported in any browser. We deal with having to support old browser versions all the time, and believe me, the W3C standards (particularly the DOM), really help to reduce the amount of logic we need to duplicate for various user agents. However, we haven't the luxury of saying, "bah, forget the old browsers, our users have only the very best". So, our server scripts output HTML 4.01 and scripts redirect on failed functional tests and noscript tags to non-script versions of the site.
The point is, CSS2 doesn't fill its intended purpose for those who must support legacy apps. Its faster to bite the bullet and format layouts with tables, and it works for ancient browsers (Netscape 4.x anyone?). To me, that's one of the main advantages of JSP, PHP, ASP, and the like: I can include complex logic in my site and output lame ole' HTML 4.01. Code and UI are separated, and everyone is happy.
Besides, take a lesson from Google, simple layouts are best.
>> they're pretty lightweight, but don't handle distributed applications well.
I wouldn't say COM is lightweight (even standard marshalled), but it does allow direct pointer access to objects created on the same thread (or in the right apartment). This removes the overhead of IPC where it isn't needed (in GUI apps yes, but this is true for any one-machine show). Java and CORBA don't use this shortcut; however, I'm not familiar with some of the examples you've given, so they very well may do so.
DCOM is a broken pile of dung, and that is why distributed apps don't fly with Microsoft. Maybe that's why.NET will be using SOAP.
Good points, but COM/DCOM/Active-X, like Java RMI, accomplish IPC through pipes and sockets, albeit managed by the COM server. The COM technologies are extremely bloated (listed by yourself in ascending bloat order).
Programming any of these unwieldly techs directly will undoubtedly test your mettle [ apartment threading + marshaling + re-entrance = complete and utter chaos ]. To their credit, Microsoft has provided an enormous set of IDE wizards and compilers (MIDL, VB) to cover the mayhem that lies beneath. However, the real advantage COM has over Java on the desktop is that the COM service runs automagically on Windows, while for Java, the user is forced to endure the endless VM load time (shudder).
.NET is a re-implementation of the COM debacle with a fresh Java-esque API. Right now, the.NET CLR is loaded the Java way, and users again sit and watch a splash screen for all eternity. Come Longhorn, the.NET CLR will be the Windows shell, and people will decide to use it. The point is, the Java way is a very good way to go. Someone should write a Java shell and app manager...
It isn't all that difficult to narrow the search when looking for exploits like this. Its surprising (or maybe it isn't) that M$ never looked for them. At our shop, its common practice to detect dangerous code.
Just search for all stack arrays in the source...
$ egrep "\[[:digit:]+\]"...
...then inspect the code for ways to read/write past the bounds. That narrows the search field quite a bit (ok, you'd miss arrays defined with #define symbols, but you'd catch the sloppy ones, which is what you want in the first place).
Combine a search as above with one for calls to strcpy(), strcmp(), sprintf(), [or any other C runtime/misc. function that fails to check input], and you have an even smaller lump of code to inspect.
So, the 13 year old wouldn't need extensive knowledge, just what you could glean from reading an article or two on buffer overflows. Still, I'd bet its a seasoned socially backward individual.
Reason 1: The forthcoming operating systems currently under development at Redmond are going to ensure that all Windows programs use.Net in some way.
But how? You ask? Thus far, systems running the CLR (the.Net runtime) have been executing it as a process. In the future, the CLR will be one of a very select group of processes that will be allowed to interface the kernal, and affect kernal-mode instructions. If you think NT-based systems are protected now, wait until the CLR becomes the runtime for the entire OS and Intel delivers the so-called "Palladium" encryption chip (which is being designed in concert with the next Windows system). The obvious entities that will be allowed to interface the kernal (or rather the kernal will interface them) will be the hardware drivers. The.Net driver framework is not yet publicly available, but rest assured, as soon as Microsoft is ready to unleash Windows.Net, Win32 drivers will not be allowed to interface the hardware. All drivers will be signed with a public key and require a cert to install. Don't have a cert? Sorry, "This is not a Windows driver"
Conclusion: you will not be allowed to interface hardware from "ummanaged" code (because MS says it is "dangerous" to let you do so), and if you could, what would stop you from running viri from the sandbox?
Reason 2: All "unmanaged" code will execute in a sandbox.
Now, all.Net dynamic libraries are signed with a public key. What that means, folks, is that the CLR will be able to verify the author of each and every dynamic library against a certification issued by Microsoft or one of its partners/acquisitions. Forget home-brew apps, they simply won't install and run on.Net Windows OS without a cert, unless MS decides to allow them to install as "unmanaged", in which case they will not have any control over hardware outside of the.Net API, and they will likely have severe restrictions as to what they are allowed to do with the filesystem and communications ports. Oh yes, and the windowing system will be controlled by the CLR as well.
Conclusion: only by interfacing.Net objects will you be able to do anything outside of raw math or data organization in your legacy code.
Reason 3: Alternative rendering platforms like OpenGL will have to be implemented within the.Net framework in order to load and use the drivers efficiently (else they could just proxy through.Net, but hey, why proxy when you can just recompile?)
I believe this is very likely to happen, because Microsoft cannot reasonably refuse to allow competition in this manner without more courtroom appearances (boy, they really took it hard last time though, right?). So you will likely be able to choose something other than DirectX, but I can almost gaurantee to you that DirectX will mysteriously outperform any and all competition. Why? Microsoft has the CLR code, and can easily add undocumented interfaces that allow DirectX to scream and everything else to crawl. They've done it before with Win32; they'll do it again I'm sure.
Overall conclusion:.Net is *NOT* a competitor for Java, it *IS* a wholesale replacement for Win32 and the current Windows operating systems. It has promised support for legacy, but all Win32 legacy will operate through.Net proxies to.Net objects. So no matter how you write your program, if you want it to run on Windows, it *WILL* rely on.Net
However, the potential for creating useful 3D widgets is something that warrants investigation...
As a crappy example, take a widget that uses floor plans at design time, and presents 3D fire escape routes, or directions around a building, or whatever, at runtime.
If I had a better, more general example that would be better suited to being a widget, than I'd go make it. The point is, their is potential there beyond eye-candy, that *could* increase productivity.
I've been to Hanover numerous times, and I'm sure the poster is aware that not every household in town can afford to lay down $40/month for this service. The school and its surrounding area are very picturesque and affluent; however, a mile or so out you have people who live very modestly. Its safe to say most of their children will not be attending Dartmouth.
I don't mean to flame, but seriously, I think we may have folks in ivory towers who are thinking $40/month is a meager cost, when in many cases it is certainly not. Perhaps by "feasibility", they mean to find out if enough of the residents will fork over forty bucks a month to support the cost of the infrastructure. Frankly, I'm a bit surprised that this is advertised as a town-wide effort, when it will most definately exclude a good number of the town's citizens.
Of course, if the millionaires at Dartmouth foot the bill, then this would seem a great public service.
I've read only a little on Grid computing (the draft of the spec mainly), and I was wondering how a number of insidious situations are handled.
From what I understand of the model of the grid service, requests recieved (be they for interfaces or references) may be handled locally by the service or forwarded to another service for handling.What happens if a ring of grid services forms in which requests are endlessly forwarded? I'll bet the dogma says that is an implementation problem, so I'll just say "ok", and move on.
The Grid specification purposely separates interfaces from implementations. That being the case, any Joe could concievably author their own implementation. If any Joe should be an evil Joe, what's to stop malicious Joe from purposely creating malfunctioning interface implementations? In such a situation, a distributed calculation could certainly go awry. In fact, they way I see it, malicious Joe has free license to introduce "bugs" into a distributed application. Before you say, "security and authentication layers, blah blah" remember malicious Joe can take a valid node implementation, and insert his own execute code any damn place he pleases.
Here's the main problem as I see it... by running a distributed application, you run the inherent risk that code is being run on a foreign system, and there is no practical way to guarantee that system is friendly. Outside of requiring a "web of trust" certificate scheme (specifically designed to exclude ALL untrusted nodes), I don't see how such a system could survive against malicious attack. To achieve some of the pipe dreams laid out in this thread of creating world-wide natural language processors and the like, you'd need a critical mass of *trusted* nodes. So, who can you trust?
If this thought is flawed, please flame it. I'm emotionally detached.
This is really a barrage of questions. What did the other prisoners think when they learned the nature of your detainment? Did you tell them you were in for armed robbery to toughen your rep? How would you rate Hollywood's penchant for prison portrayal, accurate, or way off the mark? Also, were you able to follow developments in computing through books; were you granted such a right?
Slashdot Mirror
You couldn't be more right about the collective skills of Windows "admins". Many in my experience earned a piece of paper after completing some joke course at a two-week correspondance school. However, being a programmer who directly deals with these people has inspired me to write the point and click tools myself instead of trying to hold their hand through the simplest tasks. This scripting environment looks like a very nice fit for accomplishing that task. Heck, it's designed to be the foundation for the MMC panels - the familiar stomping ground of the "certifiable".
In the past, I've always had to resort to some Frankenstein WSH + script + binaries that do all the crap WSH can't do and it's a damn mess, but still a time saver over telling numbskull after numbskull how to do their job.
The sad fact is Microsoft wants to further the notion that any chump off the street can administer your network (which really seems at odds with their insistence on heaping mounds and mounds of arcane and disorganized crap onto everything they produce). Oftentimes, the HR interviewers at these places are impressed by candidates who lack any and all skill, and people like me are left to deal with them, and that is the likely case study in play here.
Love to see Google promote this site. I haven't used mapquest in quite some time.
Show me a preacher burnt at the stake (as in real fire and real charred flesh, not metaphorically) by a council of scientists and I'll agree with you.
It was a council of scientists whose invention burned not only preachers, but civilian men, women, and children in August 1945.
Absolute power does corrupt absolutely.
My pie in the sky idea'r is to develop a genetic algorithm that's aimed at finding the optimal formula for identifying the smarties.
The basic idea is to have a ranking system (a score for each contributer's level of repute that entitles them to specialness). Here's a five-second brainstorm on some possible inputs...
To evolve the formula, one could provide recombination of the rules based on
When conducting a survey, you could weigh the responses based on reputation, and you could subject that weighting factor to survey as well. I think I've done enough babbling for now...
The goal would be that if you're trollish enough, you could be placed into exile, made to suffer review on your edits, or whatever. If you're wise enough, you could be asked to perform academic reviews, be eligible to win a free coffee mug, or some other token of superiority.
I know, the genetic algorithm thing probably isn't all that necessary, and there's always a chance it could unravel itself, but it seems to me like it would be a very interesting experiment with such a large population of contributers... Final thought: I think some incentive to be a good wiki-citizen would be a wise addition, and it doesn't need to conflict with the open nature of the project IMHO.
Performance was not a problem on my PC. Some have reported it is on theirs. I am running a P4 3.2 GHz HT w/512 MB RAM.
Now to the constructive criticism...
The memory problem is a big one. I'm guessing that the history list is largely responsible for the offense, and that some disk cacheing could remedy the problems. Garbage collection isn't a license to grab all the RAM on my PC.
Anyway, a good free program all-in-all. A bit of a heavyweight to be a Paint replacement though.
A business that outsources core competencies is headed in the wrong direction. I happen to work for a company that has experimented with outsourcing (both inside the US and offshore), and the process works for some software efforts, but certainly not for the core businesses and domain-specific developments.
If a company outsources its core businesses, it effectively reduces itself to a distributer.
I know it sounds like GNU-style recursion and a bit silly at first, but we've used this and users applaud it, from rookies and gurus.
Simply put, make the default set of options the ones that are most commonly used and easiest for beginners to understand. Add in an editor for "Experience Level" or something like that, and have that editor provide a slider (or whatever) that, when set, will gradually reveal more or less detail in the options presented to the user.
The result: new users aren't overwhelmed with settings they don't understand and probably shouldn't mess with, and advanced users can set the experience level once, and forever have every configurable setting at their fingertips.
Excellent point. We write Neurological device software, and projects past have overlooked the all-important facet of applications and domain experience on the enginerring team. Knowledge of the user's situation and of the science behind the solutions is absolutely critical in technically-challenging efforts.
Innovative solutions are generally harvested from people who truly understand the work flow of the users.
Hmm, good question. I've only heard rumors about the plans for drivers. Once I heard the driver spec was changing but not finished, then I heard it wouldn't change. I think its safe to say that Microsoft is going to try to keep existing HW partners happy, whatever becomes of the registry, or wherever its current functions land.
3. Will Longhorn keep the Windows Registry?
Absolutely
I'd expect emulated support for the registry (along with the emulated Win32 API), but the windows system itself will stow object info to the Global Assembly Cache. Configuration data will be moved to XML stores. Apps are encouraged to load config data from within the same folder as the assembly. After a spell, the registry will be deprecated (once major players have made the migration).
Hmmm, I wasn't aware of that feature; it's nice.
.NET exe, do they select access security during the install? I wouldn't guess that the default access level would sandbox every executable (though admittedly I don't know). Unless such a decision is forced during install, many users would fail to secure their machines (as is the case today).
.NET crushing the home-brew app writer. Circumvention may be the wrong term here, but I believe this could be a reasonable way to allow home-brew apps to continue without mandating certs.
Still, I can think of a number of legitimate reasons for such an interpreter to be written that includes cases where you'd want to allow it access to file systems and networks and so forth (cross-platform network utilities in Perl, for example). Of course, you'd be taking your security risks by your own hand in that case.
When a user installs a
Aside, much of the fear of Palladium in this forum has centered around
Ventriloquism.
The underlaying rules behind evolution are testible, and have been proven as well as any scientific fact can be (see the Problem of Induction in any philosophy textbook), which is why evolutionary modeling techniques are used in any field that requires predictions about complex molecules. This includes chemical engineering, medical research, and even computer software design.
Interesting examples. All fields of human creation.
Not to split heirs, but the Theory of Evolution is in fact a theory, not a fact (by the scientific definition of the words). Of course, there really aren't scientific facts, just laws, and any good Slashdot reader knows full well even laws are subject to interpretation by those who wouldn't use IANAL.
Anyway, you've laid down some good arguments/information, but this thread is missing the bones of contention against evolution: that large gaps in the evolutionary record fail to prove macro-evolution into law-dom, despite demonstrable micro-evolutionary experiments. Given that lost records may forever be lost, a fair part of evolutionary dogma amounts to speculation, and shouldn't automatically be lumped into tested and demonstrated evolutionary events as "part of the facts".
I likely fall into that group of consensus believers you mention, because I tend to accept macro-evolution as a better explanation of our world than divine creation, though I simply cannot ignore the "Argument by Design" (also in any philosophy textbook). My personal belief is that the story of creation was actually the first draft of "The Evolution of Man", albeit recorded before the Beagle was constructed and at a time when unanswerable questions were frequently punted to God (not unlike today, really).
If there aren't natural rules, then the scientific method is bogus, because tomorrow the universe could change into something entirely not like it is today. If there are such rules, how could they arise from randomness? Can something ordered arise from something random? That's my thinking anyway...
I have to ask (because I don't know), are their insurmountable technical barriers that would prevent compiling both Java and C# to the same bytecode?
The author calls for an open Java VM (which is a very good call IMHO), the natural assumption is that the runtime would execute Java bytecode, as it should. Is there a reason why C# couldn't be compiled to Java bytecode, and if so, then could extensions be added to accomodate non-Java languages?
I agree that Linux needs a solid front, but many of the issues raised speak to factions that want their technology to reign supreme on Linux. Why not have a runtime that runs all languages and let the coders decide which to use?
Aside, excellent insight into the purpose of XAML. You've got to realize that Internet Explorer Longhorn Edition is going to fully support all of the vector-based rendering APIs available to XAML's GDI/GDI+ predecessor. This means a full-featured GUI that can use a rich set of Microsoft's controls will be able to execute from inside the web browser using the same code you'd write for a local application. This is a huge deal, and whether it be XUL or something else entirely, Linux needs a equivalent alternative.
Ok, so I think the writing on the wall reads, "M$ will be requiring code to run through the .NET CLR", if it is to run on Windows.
.NET app? [Ruby was on my mind]
So, in response, we have C compiling to bytecode. But, Longhorn will require bytecode assemblies to be signed; I suppose that could be built into the compiler as well (else wouldn't we lose portability?)
I was thinking along these lines a while back, and thought to myself, "What's to stop somebody from writing an interpreter for any language (I was thinking scripting at the time) that will run as a
What's the impact of doing this, you ask? Well, if the interpreter itself is the signed certificate-backed secure executable, then any little scriptlet or homebrew app could be run without being digitally signed!
To me that allows a fairly obvious circumvention of Palladium, and "trustworthy computing" is out the door.
I'm not against CSS, I find it essential for styling, really (inline styles hamper the readability of the HTML). CSS2, on the other hand, has some nice features that I can almost never use for the reasons I previously stated.
Usually with PHP, I'll separate code from HTML by using HTML files with inline PHP:
<table><tr><th>
<% $heading_c1 %>
</th></tr></table>
or I'll call functions from imported files, etc. Though its not really relevant, I'm also starting to like XSLT for XML DB stuff. The XSLT then contains the full html representation, and the PHP is pure code.
So, I like CSS, don't get me wrong, but I usually find myself using tables for formatting.
This type of solution doesn't really fix the problem that the CSS2 W3C standards aren't correctly supported in any browser. We deal with having to support old browser versions all the time, and believe me, the W3C standards (particularly the DOM), really help to reduce the amount of logic we need to duplicate for various user agents. However, we haven't the luxury of saying, "bah, forget the old browsers, our users have only the very best". So, our server scripts output HTML 4.01 and scripts redirect on failed functional tests and noscript tags to non-script versions of the site.
The point is, CSS2 doesn't fill its intended purpose for those who must support legacy apps. Its faster to bite the bullet and format layouts with tables, and it works for ancient browsers (Netscape 4.x anyone?). To me, that's one of the main advantages of JSP, PHP, ASP, and the like: I can include complex logic in my site and output lame ole' HTML 4.01. Code and UI are separated, and everyone is happy.
Besides, take a lesson from Google, simple layouts are best.
>> they're pretty lightweight, but don't handle distributed applications well.
.NET will be using SOAP.
I wouldn't say COM is lightweight (even standard marshalled), but it does allow direct pointer access to objects created on the same thread (or in the right apartment). This removes the overhead of IPC where it isn't needed (in GUI apps yes, but this is true for any one-machine show). Java and CORBA don't use this shortcut; however, I'm not familiar with some of the examples you've given, so they very well may do so.
DCOM is a broken pile of dung, and that is why distributed apps don't fly with Microsoft. Maybe that's why
Good points, but COM/DCOM/Active-X, like Java RMI, accomplish IPC through pipes and sockets, albeit managed by the COM server. The COM technologies are extremely bloated (listed by yourself in ascending bloat order).
.NET is a re-implementation of the COM debacle with a fresh Java-esque API. Right now, the .NET CLR is loaded the Java way, and users again sit and watch a splash screen for all eternity. Come Longhorn, the .NET CLR will be the Windows shell, and people will decide to use it. The point is, the Java way is a very good way to go. Someone should write a Java shell and app manager...
Programming any of these unwieldly techs directly will undoubtedly test your mettle [ apartment threading + marshaling + re-entrance = complete and utter chaos ]. To their credit, Microsoft has provided an enormous set of IDE wizards and compilers (MIDL, VB) to cover the mayhem that lies beneath. However, the real advantage COM has over Java on the desktop is that the COM service runs automagically on Windows, while for Java, the user is forced to endure the endless VM load time (shudder).
...oh yes, and give it away for free.
It isn't all that difficult to narrow the search when looking for exploits like this. Its surprising (or maybe it isn't) that M$ never looked for them. At our shop, its common practice to detect dangerous code.
...
...then inspect the code for ways to read/write past the bounds. That narrows the search field quite a bit (ok, you'd miss arrays defined with #define symbols, but you'd catch the sloppy ones, which is what you want in the first place).
Just search for all stack arrays in the source...
$ egrep "\[[:digit:]+\]"
Combine a search as above with one for calls to strcpy(), strcmp(), sprintf(), [or any other C runtime/misc. function that fails to check input], and you have an even smaller lump of code to inspect.
So, the 13 year old wouldn't need extensive knowledge, just what you could glean from reading an article or two on buffer overflows. Still, I'd bet its a seasoned socially backward individual.
Anyway, good question to ponder.
Reason 1: The forthcoming operating systems currently under development at Redmond are going to ensure that all Windows programs use .Net in some way.
.Net runtime) have been executing it as a process. In the future, the CLR will be one of a very select group of processes that will be allowed to interface the kernal, and affect kernal-mode instructions. If you think NT-based systems are protected now, wait until the CLR becomes the runtime for the entire OS and Intel delivers the so-called "Palladium" encryption chip (which is being designed in concert with the next Windows system). The obvious entities that will be allowed to interface the kernal (or rather the kernal will interface them) will be the hardware drivers. The .Net driver framework is not yet publicly available, but rest assured, as soon as Microsoft is ready to unleash Windows .Net, Win32 drivers will not be allowed to interface the hardware. All drivers will be signed with a public key and require a cert to install. Don't have a cert? Sorry, "This is not a Windows driver"
.Net dynamic libraries are signed with a public key. What that means, folks, is that the CLR will be able to verify the author of each and every dynamic library against a certification issued by Microsoft or one of its partners/acquisitions. Forget home-brew apps, they simply won't install and run on .Net Windows OS without a cert, unless MS decides to allow them to install as "unmanaged", in which case they will not have any control over hardware outside of the .Net API, and they will likely have severe restrictions as to what they are allowed to do with the filesystem and communications ports. Oh yes, and the windowing system will be controlled by the CLR as well.
.Net objects will you be able to do anything outside of raw math or data organization in your legacy code.
.Net framework in order to load and use the drivers efficiently (else they could just proxy through .Net, but hey, why proxy when you can just recompile?)
.Net is *NOT* a competitor for Java, it *IS* a wholesale replacement for Win32 and the current Windows operating systems. It has promised support for legacy, but all Win32 legacy will operate through .Net proxies to .Net objects. So no matter how you write your program, if you want it to run on Windows, it *WILL* rely on .Net
But how? You ask? Thus far, systems running the CLR (the
Conclusion: you will not be allowed to interface hardware from "ummanaged" code (because MS says it is "dangerous" to let you do so), and if you could, what would stop you from running viri from the sandbox?
Reason 2: All "unmanaged" code will execute in a sandbox.
Now, all
Conclusion: only by interfacing
Reason 3: Alternative rendering platforms like OpenGL will have to be implemented within the
I believe this is very likely to happen, because Microsoft cannot reasonably refuse to allow competition in this manner without more courtroom appearances (boy, they really took it hard last time though, right?). So you will likely be able to choose something other than DirectX, but I can almost gaurantee to you that DirectX will mysteriously outperform any and all competition. Why? Microsoft has the CLR code, and can easily add undocumented interfaces that allow DirectX to scream and everything else to crawl. They've done it before with Win32; they'll do it again I'm sure.
Overall conclusion:
Agreed, this is eye candy.
However, the potential for creating useful 3D widgets is something that warrants investigation...
As a crappy example, take a widget that uses floor plans at design time, and presents 3D fire escape routes, or directions around a building, or whatever, at runtime.
If I had a better, more general example that would be better suited to being a widget, than I'd go make it. The point is, their is potential there beyond eye-candy, that *could* increase productivity.
I've been to Hanover numerous times, and I'm sure the poster is aware that not every household in town can afford to lay down $40/month for this service. The school and its surrounding area are very picturesque and affluent; however, a mile or so out you have people who live very modestly. Its safe to say most of their children will not be attending Dartmouth.
I don't mean to flame, but seriously, I think we may have folks in ivory towers who are thinking $40/month is a meager cost, when in many cases it is certainly not. Perhaps by "feasibility", they mean to find out if enough of the residents will fork over forty bucks a month to support the cost of the infrastructure. Frankly, I'm a bit surprised that this is advertised as a town-wide effort, when it will most definately exclude a good number of the town's citizens.
Of course, if the millionaires at Dartmouth foot the bill, then this would seem a great public service.
I've read only a little on Grid computing (the draft of the spec mainly), and I was wondering how a number of insidious situations are handled.
From what I understand of the model of the grid service, requests recieved (be they for interfaces or references) may be handled locally by the service or forwarded to another service for handling.What happens if a ring of grid services forms in which requests are endlessly forwarded? I'll bet the dogma says that is an implementation problem, so I'll just say "ok", and move on.
The Grid specification purposely separates interfaces from implementations. That being the case, any Joe could concievably author their own implementation. If any Joe should be an evil Joe, what's to stop malicious Joe from purposely creating malfunctioning interface implementations? In such a situation, a distributed calculation could certainly go awry. In fact, they way I see it, malicious Joe has free license to introduce "bugs" into a distributed application. Before you say, "security and authentication layers, blah blah" remember malicious Joe can take a valid node implementation, and insert his own execute code any damn place he pleases.
Here's the main problem as I see it... by running a distributed application, you run the inherent risk that code is being run on a foreign system, and there is no practical way to guarantee that system is friendly. Outside of requiring a "web of trust" certificate scheme (specifically designed to exclude ALL untrusted nodes), I don't see how such a system could survive against malicious attack. To achieve some of the pipe dreams laid out in this thread of creating world-wide natural language processors and the like, you'd need a critical mass of *trusted* nodes. So, who can you trust?
If this thought is flawed, please flame it. I'm emotionally detached.
This is really a barrage of questions. What did the other prisoners think when they learned the nature of your detainment? Did you tell them you were in for armed robbery to toughen your rep? How would you rate Hollywood's penchant for prison portrayal, accurate, or way off the mark? Also, were you able to follow developments in computing through books; were you granted such a right?