or you need it converted. IANAP (I'm not a publisher) but I doubt they use Word to generate the necessary typesetting for a print run, and Word is pretty bad at converting a document to anything else whilst keeping the formatting intact.
you're nuts. Drop a 3rd party project into your SCM? I agree it needs to be versioned, but if its a big installed-by-msi package and you don't have source code or even a list of the dlls it ships, then what are you supposed to do?
I know its Microsoft's recommendation to host all your projects in a single solution. I think this is a crap workaround for a broken system. You must be able to pull in dlls that are not part of your build, that are pre-built and installed where they want to be installed (eg program files/xyz). Microsoft just didn't get this when they failed to handle this. I also know that if you hold too many, performance dies. And if you use resharper (as very many do) then you'd better have a huge box with a very large amount of ram. even then I found that I had to reboot after some rebuild all tasks. That ain't a good solution at all.
version hell.. you usually *want* the latest version. Installing a security fix is required, and yet you can't drop it in, you have to go configure your app too. Right now I'm in the middle of this mess: I build with the latest security-patched dlls, ship it to my customer, and get a report back "it doesn't load". My answer of 'update your system' is met with the response that they cannot do that until the security fixes are tested and rolled out to all. So I have to downgrade my build environment. We're still in a bad place, but now we're in the worst-of-all-worlds option.
Once you realise the first time there was computerised cataloging of individuals, it was used to divvy them up into those who will be sent to the gas chamber and those who would be good blue-eyed blonds. You can understand why this is a big deal and why the law is set as it is. Even facebook doesn't get an opt-out for this.
no, you can cross-reference projects quite well, if you put them all in a humungous single solution. I never said I used an absolute path, and in fact an absolute path woudl work in my case, it's not what I was talking about.
The C++ way of doing this worked: you have an environment variable that said "look here, or here" when resolving references. Easy. Each dev could set that for the project or globally. You can do this in VS/C# projects too, but you have to do it *per project*.
So, for an example, if I build a release version of an SDK and put it in c:\builds\release, and I have a debug version in c:\dev\sdk\debug, I cannot rebuild my app to reference the release version. That may not seem to big a deal, but really is when you're trying to do configuration management correctly, so you *know* what you have and what you release.
I think the problem is that the tool assumes you build the entire thing yourself, and most of the time you don't. You need to reference 3rd party or external projects and these do not necessarily fit in whatever directory structure your project is laid out in.
As for versioning, it always uses the version built against, unless explicitly overridden. Guess what, 99% of the time you want it to use the latest version. that means a load of hasle updating your config files for each app to resolve the newer dependant dll. Or a rebuild of the lot in required when a sub-dll is changed. To see why this is a problem, just think of the security fixes that MS rolls out regularly. Imagine if every app that used those had to be updated too.
anyone who combines multiple languages in the same codebase is asking for a maintenance nightmare. This is why C# dominates all the.NET code out there, even pushing out the VB.net coders.
I would like to see better integration with the host. With.NET apps, you end up with Windows 7 : some dialogs that look one way, others that look another. Go to control panel and check out the display settings. You can change the default window background colour (I used to do this so it was just a tiny bit cream, much easier on the eyes) but only half the windows will honour it - ones like explorer will just ignore it. This kind of crapness pervades all of Windows now, and is not a good thing. That's why proper integration is a must-have, and the Windows boys and the Developer Division boys need to have their heads banged together until they learn to play nicely with each other.
GC isn't quite as good as you think, I'd much rather it had deterministic finalisation so the superior RAII pattern would work.
MS could have implemented this (if you know C++, imagine if every.NET object was allocated on the heap and the reference to it was automatically wrapped in a shared_ptr) but they didn't quite have the imagination. Hell, it took a huge discussion on the msdn forums just to get them to implement the Dispose pattern, and that was just a "this is what you can do if you want to" thing. Turns out it was quite the good idea, so much so that they made it a 1st class part of the language and added the using keyword to give you RAII-if-you-code-it-yourself.
So, I think you can easily live without GC. It doesn't mean you'd have to go back to memory management using malloc.
says a lot about a lot of Microsoft developers..NET has made it so easy that they let anyone code nowadays. Of course, you now see why that wasn't such a good idea:)
The MSDN documentation is absolute crud compared to what it used to be, so I'd give him a pass on that particular aspect. He's still clueless though.
actually, I'm finding protocol-agnostic services in WCF is pretty damn hard, it seems you have 1 choice : soap web services, and they appear to have an ever-so-slightly different interpretation of the standards compared to the Java and (I'm told) PHP libraries.
Of course, it works great when communicating between Windows WCF services!
I always thought C# wasn't a bad language, but the crap way references are handled and the lack of some things that are needed by professional programmers (eg no system wide 'include' path to pick up references, so you have great difficulty unless all your devs use the same relative path) and the side-by-side hell we now have (not to mention version manifests and the GAC) mean that I'm quite disappointed by.NET (the system framework).
Still, internal politics at Microsoft will see that its no longer the "cool" technology and so all the Microsoft-only devs will start to drop it. It happens all the time, the continual chase after the 'latest thing' in Microsoft's world will be both the making of, and the death of.NET.
Top tip: Google, when attacked for using other company's vague and frivolous patents, why not relocate to the EU thus preventing lawsuits and sticking 2 fingers up to the stupid authorities who allow such things in the first place.:-)
possibly CIL or LLVM, but the point is that any new device still has to have a load of dev work done to allow Dalvik to run on it, a C based API wouldn't require much in the way of additional work for the manufacturer, and none for the app-developer.
With a C based API, you get to run anything on top of it. With Java you only get java-based stuff (ie Java) to run and that just annoys me:)
yup, it sounds like the email is a nerd's response to being asked to choose something other than his favourite technology... "we've been over a hundred of these" and the *only* one that I think is good enough is Java, of course. Just be thankful it wasn't someone who thought C# was the ultimate in all language technologies.
My position: C (maybe C++) would have been ideal for a low-level API that you then build on top of. In whatever language/technology you like once you have that API library established.
I think patent law says anything can be patented with only the most cursory of oversight.
eg, the austrlian man who patented the wheel. Apparently there have been 30,000 patents granted by the US office concerning slight improvements on the wheel.
don't underestimate the Chinese looking at the current debt crisis plays in the US and thinking "WTF, these clowns are controlling our interbank currency". I can imagine a lot of dollars will be sold off as the Chinese reduce their huge dependance on the dollars you sent them, I think they'll buy euros (they've already started) as its hardly more f**** up than the dollar.
however, its slightly mitigated in that you can't magic items out of thin air - ie, the game balance might just be kept if the fancy items simply change hands from one player to another.
Its not like they are allowing you to buy skill points, which would be terribly bad. I guess it just legitimises those craigslist transactions (which you can't really stop if one player "decides" to give his fancy item to another player), and allows Blizzard to grab a little fee as thoseplayers do it, which they would go ahead and do anyway.
1. make sure the code is separately documented with the GPL licences in place, or they could claim it belonged to them in the first place and it was you that stole it. 2. contact the EFF 3. sue for copyright violation 4. profit?
something like that. step 2 is probably the most sensible part.
and can you imagine that this won't happen again. "oh dear, I accidentally pressed 0 a few too many times, whoops. silly me."
and the computers make a killing for their employers, the bad trade gets correctly later and all the small investors who panicked lose out.
I think the only moral story to this is that the small investor needs to take a much longer term view to the stock market - you just can't beat these guys at their own game ('cos they've rigged it against you)
nope, wrong, sorry. Don't expect me to explain next time it goes poof.
With HDDs you sometimes get warnings its about to fail. Net result: just as unsafe as SSDs, as we're managing risk here it's not about the 99.99999% of the time that they work, its about that last tiny chance of failure. When you put the two side-by-side, that chance is still there even with HDDs, so there's realistically no difference between them.
I use HDDs, the cost is too great compared to the performance gain of SSD. But reliability between them would never be factored into my choice.
I also use continuous backups. See acronis, timemachine or r1soft for examples.
hey! even better, you could find out where Bill G goes, and follow him around. They might change their mind thinking this is ok after that happens a few times.
and I guess that means 'on the desktop (or bedroom TV)' too.
Now if someone can come up with a set of teaching aids, or lessons that show a teacher what to do with this device, demonstrating computing principles as it goes, then there's really no reason not to buy one of these for every schoolkid in the world.
I might have to buy some ARM stock if governments collectively place an order for a few billion of these:)
IIRC its USB at one end, HDMI at the other, and will be powered by the HDMI port. The usb is for keyboards and other peripherals to connect to it. The Model B will have a ethernet port in the middle.
Slashdot Mirror
or you need it converted. IANAP (I'm not a publisher) but I doubt they use Word to generate the necessary typesetting for a print run, and Word is pretty bad at converting a document to anything else whilst keeping the formatting intact.
you're nuts. Drop a 3rd party project into your SCM? I agree it needs to be versioned, but if its a big installed-by-msi package and you don't have source code or even a list of the dlls it ships, then what are you supposed to do?
I know its Microsoft's recommendation to host all your projects in a single solution. I think this is a crap workaround for a broken system. You must be able to pull in dlls that are not part of your build, that are pre-built and installed where they want to be installed (eg program files/xyz). Microsoft just didn't get this when they failed to handle this.
I also know that if you hold too many, performance dies. And if you use resharper (as very many do) then you'd better have a huge box with a very large amount of ram. even then I found that I had to reboot after some rebuild all tasks. That ain't a good solution at all.
version hell.. you usually *want* the latest version. Installing a security fix is required, and yet you can't drop it in, you have to go configure your app too. Right now I'm in the middle of this mess: I build with the latest security-patched dlls, ship it to my customer, and get a report back "it doesn't load". My answer of 'update your system' is met with the response that they cannot do that until the security fixes are tested and rolled out to all. So I have to downgrade my build environment. We're still in a bad place, but now we're in the worst-of-all-worlds option.
yup, this is Germany.
Once you realise the first time there was computerised cataloging of individuals, it was used to divvy them up into those who will be sent to the gas chamber and those who would be good blue-eyed blonds. You can understand why this is a big deal and why the law is set as it is. Even facebook doesn't get an opt-out for this.
those kind of devs should stick to VB :)
no, you can cross-reference projects quite well, if you put them all in a humungous single solution.
I never said I used an absolute path, and in fact an absolute path woudl work in my case, it's not what I was talking about.
The C++ way of doing this worked: you have an environment variable that said "look here, or here" when resolving references. Easy. Each dev could set that for the project or globally. You can do this in VS/C# projects too, but you have to do it *per project*.
So, for an example, if I build a release version of an SDK and put it in c:\builds\release, and I have a debug version in c:\dev\sdk\debug, I cannot rebuild my app to reference the release version. That may not seem to big a deal, but really is when you're trying to do configuration management correctly, so you *know* what you have and what you release.
I think the problem is that the tool assumes you build the entire thing yourself, and most of the time you don't. You need to reference 3rd party or external projects and these do not necessarily fit in whatever directory structure your project is laid out in.
As for versioning, it always uses the version built against, unless explicitly overridden. Guess what, 99% of the time you want it to use the latest version. that means a load of hasle updating your config files for each app to resolve the newer dependant dll. Or a rebuild of the lot in required when a sub-dll is changed. To see why this is a problem, just think of the security fixes that MS rolls out regularly. Imagine if every app that used those had to be updated too.
anyone who combines multiple languages in the same codebase is asking for a maintenance nightmare. This is why C# dominates all the .NET code out there, even pushing out the VB.net coders.
I would like to see better integration with the host. With .NET apps, you end up with Windows 7 : some dialogs that look one way, others that look another. Go to control panel and check out the display settings. You can change the default window background colour (I used to do this so it was just a tiny bit cream, much easier on the eyes) but only half the windows will honour it - ones like explorer will just ignore it. This kind of crapness pervades all of Windows now, and is not a good thing. That's why proper integration is a must-have, and the Windows boys and the Developer Division boys need to have their heads banged together until they learn to play nicely with each other.
GC isn't quite as good as you think, I'd much rather it had deterministic finalisation so the superior RAII pattern would work.
MS could have implemented this (if you know C++, imagine if every .NET object was allocated on the heap and the reference to it was automatically wrapped in a shared_ptr) but they didn't quite have the imagination. Hell, it took a huge discussion on the msdn forums just to get them to implement the Dispose pattern, and that was just a "this is what you can do if you want to" thing. Turns out it was quite the good idea, so much so that they made it a 1st class part of the language and added the using keyword to give you RAII-if-you-code-it-yourself.
So, I think you can easily live without GC. It doesn't mean you'd have to go back to memory management using malloc.
says a lot about a lot of Microsoft developers. .NET has made it so easy that they let anyone code nowadays. Of course, you now see why that wasn't such a good idea :)
The MSDN documentation is absolute crud compared to what it used to be, so I'd give him a pass on that particular aspect. He's still clueless though.
actually, I'm finding protocol-agnostic services in WCF is pretty damn hard, it seems you have 1 choice : soap web services, and they appear to have an ever-so-slightly different interpretation of the standards compared to the Java and (I'm told) PHP libraries.
Of course, it works great when communicating between Windows WCF services!
I always thought C# wasn't a bad language, but the crap way references are handled and the lack of some things that are needed by professional programmers (eg no system wide 'include' path to pick up references, so you have great difficulty unless all your devs use the same relative path) and the side-by-side hell we now have (not to mention version manifests and the GAC) mean that I'm quite disappointed by .NET (the system framework).
Still, internal politics at Microsoft will see that its no longer the "cool" technology and so all the Microsoft-only devs will start to drop it. It happens all the time, the continual chase after the 'latest thing' in Microsoft's world will be both the making of, and the death of .NET.
sure, but a lot of people just aren't tall enough to plug their laptops in with your solution. :-)
Is it me, or am I reading patent ideas into everything now?
Why didn't Google patent the street-view car concept and thus demand licences from Microsoft for copying yet another of their innovations.
Top tip: Google, when attacked for using other company's vague and frivolous patents, why not relocate to the EU thus preventing lawsuits and sticking 2 fingers up to the stupid authorities who allow such things in the first place. :-)
possibly CIL or LLVM, but the point is that any new device still has to have a load of dev work done to allow Dalvik to run on it, a C based API wouldn't require much in the way of additional work for the manufacturer, and none for the app-developer.
With a C based API, you get to run anything on top of it. With Java you only get java-based stuff (ie Java) to run and that just annoys me :)
yup, it sounds like the email is a nerd's response to being asked to choose something other than his favourite technology... "we've been over a hundred of these" and the *only* one that I think is good enough is Java, of course. Just be thankful it wasn't someone who thought C# was the ultimate in all language technologies.
My position: C (maybe C++) would have been ideal for a low-level API that you then build on top of. In whatever language/technology you like once you have that API library established.
I think patent law says anything can be patented with only the most cursory of oversight.
eg, the austrlian man who patented the wheel. Apparently there have been 30,000 patents granted by the US office concerning slight improvements on the wheel.
I think you'll find that this is *on a mobile device*, which makes it entirely different again...
don't underestimate the Chinese looking at the current debt crisis plays in the US and thinking "WTF, these clowns are controlling our interbank currency". I can imagine a lot of dollars will be sold off as the Chinese reduce their huge dependance on the dollars you sent them, I think they'll buy euros (they've already started) as its hardly more f**** up than the dollar.
however, its slightly mitigated in that you can't magic items out of thin air - ie, the game balance might just be kept if the fancy items simply change hands from one player to another.
Its not like they are allowing you to buy skill points, which would be terribly bad. I guess it just legitimises those craigslist transactions (which you can't really stop if one player "decides" to give his fancy item to another player), and allows Blizzard to grab a little fee as thoseplayers do it, which they would go ahead and do anyway.
1. make sure the code is separately documented with the GPL licences in place, or they could claim it belonged to them in the first place and it was you that stole it.
2. contact the EFF
3. sue for copyright violation
4. profit?
something like that. step 2 is probably the most sensible part.
So its essentially a dropbox clone?
but without the security and privacy issues?
and can you imagine that this won't happen again. "oh dear, I accidentally pressed 0 a few too many times, whoops. silly me."
and the computers make a killing for their employers, the bad trade gets correctly later and all the small investors who panicked lose out.
I think the only moral story to this is that the small investor needs to take a much longer term view to the stock market - you just can't beat these guys at their own game ('cos they've rigged it against you)
nope, wrong, sorry. Don't expect me to explain next time it goes poof.
With HDDs you sometimes get warnings its about to fail. Net result: just as unsafe as SSDs, as we're managing risk here it's not about the 99.99999% of the time that they work, its about that last tiny chance of failure. When you put the two side-by-side, that chance is still there even with HDDs, so there's realistically no difference between them.
I use HDDs, the cost is too great compared to the performance gain of SSD. But reliability between them would never be factored into my choice.
I also use continuous backups. See acronis, timemachine or r1soft for examples.
hey! even better, you could find out where Bill G goes, and follow him around. They might change their mind thinking this is ok after that happens a few times.
and I guess that means 'on the desktop (or bedroom TV)' too.
Now if someone can come up with a set of teaching aids, or lessons that show a teacher what to do with this device, demonstrating computing principles as it goes, then there's really no reason not to buy one of these for every schoolkid in the world.
I might have to buy some ARM stock if governments collectively place an order for a few billion of these :)
IIRC its USB at one end, HDMI at the other, and will be powered by the HDMI port. The usb is for keyboards and other peripherals to connect to it.
The Model B will have a ethernet port in the middle.