There must be a group of masochists over at MS. Apps outside the browser? Are they insane.
You guys are like stuck records. Read before you write, please. Taking a silverlight app out of the browser window and putting it into it's own window doesn't change it's security permissions at all. The security implications are identical
I'm sure the sample exploit code is already out there.
You think there are exploits already? Give us a link or STFU.
This is much the question as one asked below, so I'll give much the same answer:
Silverlight is a subset of desktop WPF. This will continue to be the case. WPF is not being phased out. Silverlight doesn't "obsolete" WPF, Silverlight *is* WPF. Learn one, you know the other, mostly.
There will always be scenarios where you need a larger framework than can fit in Sivlerlight's 5Mb download, and you need full access to the machine's resources that silverlight programs across the wild internet can't do for security reasons. That's where full WPF can give you a good UI.
Also, the non-Ui.Net class library in Silverlight is also brutally cut down to fit into 5mb. In many cases, we'll want and need the real thing to code a desktop app.
Visual Studio 2010 will be the first big WPF application to be widely shipped. You won't see big apps like MS word, Excel, etc written in silverlight, but you may well see them in WPF.
"Am I missing something or does that part about "apps outside the browser" sound like a more modern reimplementation of the old ActiveX? By that I mean, whether it's "inside the browser" or in a different window, this still amounts to running executable code from remote hosts."
What you're missing is that ActiveX ran compiled binary machine code from a remote host. No sandbox, full access to the OS. No platform-independence either, because of that.
Silverlight code (or Flash/Flex code for that matter) is bytecode. It runs (in or out of the browser, no difference) in a sandbox, and is platform-independent bytecode. Like java. Remember java in the browser?
Silverlight is a subset of desktop WPF. Silverlight doesn't "obsolete" WPF, Silverlight *is* WPF. Learn one, you know the other, mostly.
There will always be scenarios where you need a larger framework than can fit in Sivlerlight's 5Mb download, and you need full access to the machine's resources that silverlight programs across the wild internet can't do for security reasons. That's where full WPF can give you a good UI. Visual Studio 2010 will be the first big WPF application to be widely shipped.
. They'll get a bunch of Visual Studio programmers to use it, and then a bunch of companies will use it for their internal stuff
That's already happening for graphics-rich Intranet apps. Traders in banks, that kind of thing. Lots of Silverlight work happening there. I've seen it.
Seriously, I fail to see the difference between this and just downloading an executable off the internet and running it
There is a big difference - Silverlight is a lot more secure. The Silverlight app is able to do a lot less to your system. Mainly it can't read and write any part of your file system like a downloaded.exe can.
Icebike asked: What could Possibly go wrong with that?!?
You tell me.
It's in the same security sandbox as when it's running in the browser - it doesn't have the ability to read or write the file system outside of it's own size-limited isolated storage bin, it can't take keyboard input when full-screen, has no access to webcams and mikes, and it can't send or receive data at websites that it didn't download from unless they opt in.
Maybe you had something specific in mind that nobody else had thought of in the last few years?
you'd be surprised how many people think Gates/M$ invented the Internet
You're right, I would.
Also, get over spelling "Microsoft" "M$" - it's so 1999. It's similar to right-wing nuts who intentionally misspell your new president's name. If you've got a valid argument, you don't need the cheap smear.
I didn't say portable. Having done it, it's *way* easier to make an app look and move exactly the same on a mac and a Windows box using Silverlight than it is using html/JavaScript.
Flash/Silverlight... I can't exactly work on a web application when the internet is down
Yes, you can exactly do that. Or will, soon, if it's coded like that. Silverlight out of browser apps (and, I suppose, Adobe AIR apps) can run without network. Better yet, the coder can detect that there's no network, and keep data locally for a later sync.
There is not a single advantage that Flash or Silverlight really have if HTML, JavaScript and CSS can make application-like things in the browser?
A nicer programming model. C# may not be for everyone, but lots of people know it, like it, and prefer it over flash or JavaScript.
Easier to mix graphics and text in Silverlight than in html.
Also, easier to make pixel-precise layouts across browsers and OSs.
Flash and Silverlight aren't any faster
Javascript has gotten lots faster lately, but I think compiled C# bytecode is still faster.
Except IE, which doesn't support, and has not announced plans to support, anything
Microsoft will very shortly support H.264 - via Silverlight 3. Silveright 3 also allows developers to write their own codecs to plug into it. It will be interesting to see how long it is until there's a "codec pack" on codeplex or googlecode that includes.ogg.
So what about the IE browser without any plugins? Maybe it depends which team inside MS wins that power struggle.
Unless, of course, you want to argue that there's "artistry" in deciding what kind of information to put on the map
Maps are a lot smaller than the territory they represent. They leave out most stuff. How could there not be skill and judgement (i.e. Artistry) in choosing what to show?
Maps are the presentation of data, not the data itself.
I have put enough front ends on databases to know that it's not much of a distinction. And likely to be less relevant as more maps become software allowing multiple views of the same data, not paper. Also, it's worth noting that the watermarks seem to be added to maps at the database not the presentation.
Code size: Well, C# is a pretty verbose language, much like Java. Usually you need to write a lot of "wrapping-paper" code to do what you need the program to do. That helps when you prefer a lot of subprojects that should behave alike, but that's not what we like to do in UNIX (We like to stitch our system together with small applications that do their tasks and only their tasks well.).
It's true that both C# and Java require a bit of Wrapper code before you get started, e.g.
namespace MyProgram.Foo {
public class Fred
{
public void SomeMethod()
{// actually get started here
The reason for that is for organising large bodies of code. Which is exactly why C++ has namespaces too. I'm not sure why you think this is not "Unixy" - two of those systems, C++ and Java, come from UNIX land. Suggesting that nobody ever writes large applications on UNIX is absurd, applications of all sizes have their uses on any operating system. I'm not talking about OS utilities like "ls" and "more" here. Accounting, stock trading or CRM packages aren't constructed out of small utils and command-line pipes.
Your original post was about "small, lean" applications, and I think you're mixing up the verbosity of the source code and the size of the resulting executable, which are two very different things. C# and Java optimise the source for readability.
The code inside a C# method can be terse if you choose to write it that way. Here's a line that I wrote recently: viewModel.AddList(groupLinks.Select(gl => new GroupFilterSelection(gl)));
Which constructs a list of objects and adds them to another list.
"C# "application".. calling something written in a scripting language anything other than a script"
What exactly is your criteria for calling a language a "scripting" language? I am curious, since if you consider C# a scripting language (and Java too, I suppose, they have similar architectures) you must have a very odd definition of scripting language. Or you're just trolling.
We can't expect small, lean applications written in C# because of the language's design.
Why not? What design feature stops this?
C# is only good for writing code blazingly fast. Which is kind of silly to me, because as a semi-experienced programmer, I know that writing code is the easier part of software development.
Indeed, you need readable, maintainable, performant code. Which is why I use C#. You were expecting perl maybe?
What I said was "which cause cancer when they go wrong.".
I made no statement one way or the other about how often they go wrong. Anyone who is arguing that point is arguing from their own agenda, not mine, against someone else.
Nuclear is (or should be), without a doubt, the biggest part of the picture.
Why?
And if we finally get fusion to work within the next few decades, it should be fairly easy to convert existing nuke plants, making them even safer.
Are you sure about that? How much do you know about fission and fusion reactors? I don't know much, but from what I've seen they have very little in common. What makes you say that fusion is safer?
I'm simplifying. there are all kinds of health risks from radiation release. And a whole different set of health risks from plants that burn stuff. But dead is dead.
I'm also simplifying; nuclear is probably part of the picture; and solar, which also does not pollute during use.
You're going to have a choice of what to put in your collective backyards: Nuclear power stations, which cause cancer when they go wrong. Coal power stations, which cause cancer. Or wind turbines which... go round and round.
Slashdot Mirror
Famous last words.
What, it's a mistake to say that silverlight is more secure than something with no security at all? It's not exactly a high bar to clear.
There must be a group of masochists over at MS. Apps outside the browser? Are they insane.
You guys are like stuck records. Read before you write, please. Taking a silverlight app out of the browser window and putting it into it's own window doesn't change it's security permissions at all. The security implications are identical
I'm sure the sample exploit code is already out there.
You think there are exploits already? Give us a link or STFU.
This is much the question as one asked below, so I'll give much the same answer:
Silverlight is a subset of desktop WPF. This will continue to be the case. WPF is not being phased out. Silverlight doesn't "obsolete" WPF, Silverlight *is* WPF. Learn one, you know the other, mostly.
There will always be scenarios where you need a larger framework than can fit in Sivlerlight's 5Mb download, and you need full access to the machine's resources that silverlight programs across the wild internet can't do for security reasons. That's where full WPF can give you a good UI.
Also, the non-Ui .Net class library in Silverlight is also brutally cut down to fit into 5mb. In many cases, we'll want and need the real thing to code a desktop app.
Visual Studio 2010 will be the first big WPF application to be widely shipped. You won't see big apps like MS word, Excel, etc written in silverlight, but you may well see them in WPF.
"Am I missing something or does that part about "apps outside the browser" sound like a more modern reimplementation of the old ActiveX? By that I mean, whether it's "inside the browser" or in a different window, this still amounts to running executable code from remote hosts."
What you're missing is that ActiveX ran compiled binary machine code from a remote host. No sandbox, full access to the OS. No platform-independence either, because of that.
Silverlight code (or Flash/Flex code for that matter) is bytecode. It runs (in or out of the browser, no difference) in a sandbox, and is platform-independent bytecode. Like java. Remember java in the browser?
Silverlight is a subset of desktop WPF. Silverlight doesn't "obsolete" WPF, Silverlight *is* WPF. Learn one, you know the other, mostly.
There will always be scenarios where you need a larger framework than can fit in Sivlerlight's 5Mb download, and you need full access to the machine's resources that silverlight programs across the wild internet can't do for security reasons. That's where full WPF can give you a good UI.
Visual Studio 2010 will be the first big WPF application to be widely shipped.
. They'll get a bunch of Visual Studio programmers to use it, and then a bunch of companies will use it for their internal stuff
That's already happening for graphics-rich Intranet apps. Traders in banks, that kind of thing. Lots of Silverlight work happening there. I've seen it.
Seriously, I fail to see the difference between this and just downloading an executable off the internet and running it
There is a big difference - Silverlight is a lot more secure. The Silverlight app is able to do a lot less to your system. Mainly it can't read and write any part of your file system like a downloaded .exe can.
Icebike asked: What could Possibly go wrong with that?!?
You tell me.
It's in the same security sandbox as when it's running in the browser - it doesn't have the ability to read or write the file system outside of it's own size-limited isolated storage bin, it can't take keyboard input when full-screen, has no access to webcams and mikes, and it can't send or receive data at websites that it didn't download from unless they opt in.
Maybe you had something specific in mind that nobody else had thought of in the last few years?
you'd be surprised how many people think Gates/M$ invented the Internet
You're right, I would.
Also, get over spelling "Microsoft" "M$" - it's so 1999. It's similar to right-wing nuts who intentionally misspell your new president's name. If you've got a valid argument, you don't need the cheap smear.
I didn't say portable. Having done it, it's *way* easier to make an app look and move exactly the same on a mac and a Windows box using Silverlight than it is using html/JavaScript.
Flash/Silverlight ... I can't exactly work on a web application when the internet is down
Yes, you can exactly do that. Or will, soon, if it's coded like that. Silverlight out of browser apps (and, I suppose, Adobe AIR apps) can run without network. Better yet, the coder can detect that there's no network, and keep data locally for a later sync.
There is not a single advantage that Flash or Silverlight really have if HTML, JavaScript and CSS can make application-like things in the browser?
A nicer programming model. C# may not be for everyone, but lots of people know it, like it, and prefer it over flash or JavaScript.
Easier to mix graphics and text in Silverlight than in html.
Also, easier to make pixel-precise layouts across browsers and OSs.
Flash and Silverlight aren't any faster
Javascript has gotten lots faster lately, but I think compiled C# bytecode is still faster.
Except IE, which doesn't support, and has not announced plans to support, anything
Microsoft will very shortly support H.264 - via Silverlight 3. Silveright 3 also allows developers to write their own codecs to plug into it. It will be interesting to see how long it is until there's a "codec pack" on codeplex or googlecode that includes .ogg.
So what about the IE browser without any plugins? Maybe it depends which team inside MS wins that power struggle.
Unless, of course, you want to argue that there's "artistry" in deciding what kind of information to put on the map
Maps are a lot smaller than the territory they represent. They leave out most stuff. How could there not be skill and judgement (i.e. Artistry) in choosing what to show?
Maps are the presentation of data, not the data itself.
I have put enough front ends on databases to know that it's not much of a distinction. And likely to be less relevant as more maps become software allowing multiple views of the same data, not paper. Also, it's worth noting that the watermarks seem to be added to maps at the database not the presentation.
Gee - last I heard - you couldn't copyright a database.
Are you sure about that? Maps are databases.
Unfortunately, these TSA knuckle draggers are unable to distinguish reality from fantasy
Not that it's very uncommon.
Code size: Well, C# is a pretty verbose language, much like Java. Usually you need to write a lot of "wrapping-paper" code to do what you need the program to do. That helps when you prefer a lot of subprojects that should behave alike, but that's not what we like to do in UNIX (We like to stitch our system together with small applications that do their tasks and only their tasks well.).
It's true that both C# and Java require a bit of Wrapper code before you get started, e.g.
namespace MyProgram.Foo
{
public class Fred
{
public void SomeMethod()
{
The reason for that is for organising large bodies of code. Which is exactly why C++ has namespaces too. I'm not sure why you think this is not "Unixy" - two of those systems, C++ and Java, come from UNIX land. Suggesting that nobody ever writes large applications on UNIX is absurd, applications of all sizes have their uses on any operating system. I'm not talking about OS utilities like "ls" and "more" here. Accounting, stock trading or CRM packages aren't constructed out of small utils and command-line pipes.
Your original post was about "small, lean" applications, and I think you're mixing up the verbosity of the source code and the size of the resulting executable, which are two very different things. C# and Java optimise the source for readability.
The code inside a C# method can be terse if you choose to write it that way. Here's a line that I wrote recently:
viewModel.AddList(groupLinks.Select(gl => new GroupFilterSelection(gl)));
Which constructs a list of objects and adds them to another list.
You need to find another word, since that word "scripting", it does not mean what you think it means.
"C# "application" .. calling something written in a scripting language anything other than a script"
What exactly is your criteria for calling a language a "scripting" language? I am curious, since if you consider C# a scripting language (and Java too, I suppose, they have similar architectures) you must have a very odd definition of scripting language. Or you're just trolling.
We can't expect small, lean applications written in C# because of the language's design.
Why not? What design feature stops this?
C# is only good for writing code blazingly fast. Which is kind of silly to me, because as a semi-experienced programmer, I know that writing code is the easier part of software development.
Indeed, you need readable, maintainable, performant code. Which is why I use C#. You were expecting perl maybe?
What I said was "which cause cancer when they go wrong.".
I made no statement one way or the other about how often they go wrong. Anyone who is arguing that point is arguing from their own agenda, not mine, against someone else.
Why should I restrict myself to the US?
Even Windscale "caused an estimated 200 additional cancer cases"
Nuclear is (or should be), without a doubt, the biggest part of the picture.
Why?
And if we finally get fusion to work within the next few decades, it should be fairly easy to convert existing nuke plants, making them even safer.
Are you sure about that? How much do you know about fission and fusion reactors? I don't know much, but from what I've seen they have very little in common. What makes you say that fusion is safer?
I'm simplifying. there are all kinds of health risks from radiation release. And a whole different set of health risks from plants that burn stuff. But dead is dead.
I'm also simplifying; nuclear is probably part of the picture; and solar, which also does not pollute during use.
You're going to have a choice of what to put in your collective backyards: ... go round and round.
Nuclear power stations, which cause cancer when they go wrong.
Coal power stations, which cause cancer.
Or wind turbines which