I might be missing something, but how is it significantly different from the work on languages such as WSDL [wikipedia.org] used to describe Web Services?
It specifies a JavaScript API and a basic end-user interaction model, which isn't part of the WS-* family of standards, and its about a billionth the weight of a web services standard because the actual markup doesn't encode very much at all.
A complete definition of a service (a handler for an intent) is a single tag with three attributes, and other than the (pretty small) JavaScript API, that's all there is to it.
I have often wondered how does a book based on pure fantasy become "outdated"
Games, including RPGs, aren't based on pure fantasy. Sure, the setting and story are based on fantasy, but game system designs draws from an evolving palette of tools to achieve the desired ends.
How about we try a new roll playing game where everyone acts like adults and business people and resolve their differences without suing everyone and invoking copyrights, trademarks and patents?
Wait, do you want something where everyone acts like adults and business people? Or do you want something where everyone resolves their differences without suing everyone and invoking copyrights, trademarks, and patents?
Because, in the real world, "adults and business people" actually are usually the ones using lawsuits invoking copyrights, trademarks, and patents in resolving their differences.
The app market. It's useful for software developers to see the entire platform when determining what to code/port their software for/to. Obviously they'll take other factors into account as well, but knowing how large various operating systems are, over all devices, is important.
So yes, the iPad, iPod Touch, and iPhone are all in a single market.
You seem to be describing as the "app market" the "market of things that run software that developers might want to target". While that might be an analytically useful market, its not usually the market iOS to Android comparisons are made in, and it includes as major players things that aren't usually included in iOS vs. Android comparisons (like Windows.)
Though app developers, even on OS's that nominally support a wide range of devices of different form factors, frequently target specific form factors, so I'm not convinced that, even from a developers perspective, even the narrower "mobile app platform" market that includes tablets, phones, and phone-sized-non-phone devices is really a coherent single market.
And aside from form factor, there is also an important distinction for lots of developers between phone and non-phone devices.
Don't worry, even if every Mac ran iOS tomorrow, people would still make inaccurate marketshare comparisons between the entire Android platform of devices and just one single iOS device, the iPhone.
The most common comparison I've seen is mobile phone marketshare comparing Android phones (of which there are many) to iPhones (of which there are several models on the market at any one time, not "one single device".)
This isn't the whole universe of Android devices (which include tablets, dual-boot laptops, and I think some dual-boot desktops) against a single iOS device.
With iPads and iPods included, iOS far surpasses Android in marketshare
What analytically useful market exists that includes iPads, iPods, and the iPhone as part of the same market?
It doesn't. I've seen the kind of brittleness described upthread with every language I've seen development done in, and its been around longer than Java (and, obviously, also.NET) has.
It seems, IME, to be more common on large projects, so its probably more common at any given time in the languages that are used mostly for large enterprise systems.
What recent unsettling behavior at MS concerning.NET? All I've heard about is Microsoft ditching Silverlight for HTML5
And even that seems to be overblown over a Windows 8 demo that focussed on the fact that Win8 supports HTML5-based desktop apps, rather than anything concrete. In fact, given the release of Visual Studio Light Switch, I'd say Microsoft is doubling down on Silverlight for line-of-business app development.
If C# compiled and ran 20% faster than VB, I could understand the animosity
Performance of compiled code isn't the only important productivity contributor.
For all the MS bashing, this is one thing they did right with ASP.NET. Let people choose the language they want to work in, but produce the same results in the end.
Planning.NET (this isn't specific at all to ASP.NET, so I don't know why you would refer to that) from the outset as a multilanguage VM was a good choice. And I understand the market reasons why VB.NET (to transition VB users -- both desktop and ASP -- onto the platform) and C# (to provide a migration path for Java users) were the choices. And I know why the feature sets of the two languages are so closely aligned. The design decisions make perfect sense if you are Microsoft. They're just a headache if you aren't Microsoft.
This is Slash "Freedom of Choice" Dot, but we must kill off languages we don't like...
I have an aesthetic distaste for VB.NET and wish it would fade over time to reduce unproductive complexity on projects I run into, but I certainly wouldn't say I must kill it off, just that the IT world would be a better place if it were to fade away.
Really, if it wasn't for VB, you would have less people to feel superior to.
I don't feel superior to people who use VB.NET, I just wish it would go away since it doesn't (unlike F#, IronRuby, IronPython, or any of quite a lot of other languages that run on.NET that aren't C#) have any compelling use case to favor it over C#, but I keep running into environments where the two are mixed with no real rationale for the use of each language. Diversity that adds value is good, diversity that adds support overhead without adding value isn't.
Not by the time financial transaction software developers like Fidelity Information Services get a hold of it. How is running a daemon compiled together with it's monitor in a GUI-based.COM object even remotely "working pretty damn well"? Don't get me wrong, I've heard all the fairy tale applications for.NET, and sure it could have some uses.. But any.NET app I've ever seen has been a nightmare. Had to build server images with very specific versions of every single OS patch and interpretor, otherwise the thing went tits up... This is not what.NET was "supposed" to be about, but in the end it was utter crap.
.NET doesn't magically stop people from developing brittle, poorly designed software. That's what you get competent developers and give them the resources they need to do the job right for. Or, at least, if you don't, you shouldn't blame the platform.
Yeah, look at the flop that is asp.net, or how hard doing protocol agnostic services with WCF is. *sigh*.NET is a huge success in the corporate world, and hopefully c# will be one of the last nails in VB's coffin.
C# has been around with.NET since.NET 1.0 and VB is still going strong. If Microsoft had kept supporting and actively pushed IronRuby and/or IronPython, they might have combined with C# to displace VB.NET
Actually that's exactly what frustrates a lot of people who want to write web applications that run as a different user than the user account that holds the application...
It shouldn't, because while it integrates by default, its trivial to login as any database user from any system account.
Even if you do have an environment where the web server is running as the user account, such as php safe mode, or ruby on rails with a passenger phusion server, that prohibits you from having different login credentials for different apps.
No, it doesn't. It is no harder to use different logins for different apps than it is for MySQL. In fact, in most database abstraction libraries, you do it in almost exactly the same way with Postgres as you would with MySQL.
Yes, postgresql can do thing like mysql, but it has to be be configured in a remote, strangely named config file.
Sure, pg_hba.conf is a strangely-named file, but its well-documented what it is and what its format is and where it is located. More importantly, though, the defaults don't prohibit connections to different DB accounts from the same system account, so you don't actually need to touch it to enable the usage you refer to.
I just wish it was a little more user friendly. That was the one thing MySQL had going for it.. dead simple to use and admin..
PostgreSQL is, IME, dead simple to use and administer, at least in versions from the last half-decade. Before that it had a possibly-earned reputation for complexity in administration and some issues on Windows particularly, but that's not really the case any more.
What would be the technical issue of setting up a more flexible social network? Multiple social networks which supply feeds to each other. Shouldn't be too hard from a technical PoV.
Trivial from a technical PoV; communications protocols like PubSubHubbub, and XMPP, and social graph data representations like FOAF and XFN, and authentication protocols like OpenID already support just about all of of what you need to replicate the functions common in modern social networking sites in an open, easily federated network.
Marketing seems to be the big blockage.
Getting the people who have a theoretical interest in such a thing to actually go beyond the technical underpinnings which would allow it to be built and to actually build something on those underpinnings that would be useful to users (individual or institutional) seems to be the biggest problem, not marketing the solutions once they are built.
Because frankly, we already have a cathedral (LinkedIn) and a Bazaar (Facebook), so if Google wants to attract those users, they better be flexible enough to accommodate them.
Google already supports "bazaar"-style social networking (much moreso than does Facebook) via a variety of open APIs for communication and social data and support for open social tagging standards that can be used on any webpage no matter who hosts it that Google will crawl to derive and present social graph data. (OpenSocial API, Social Graph API [which provides access to data that users present on their own pages via XFN or FOAF markup], PubSubHubbub protocol and the open reference hub supporting it, etc., etc., etc., ad nauseum, ad-almost-fricking-infinitum.)
There's nothing wrong with using a SSN as an identification. [The problem is when you use it as authentication.]
Other than the fact that my Social Security Card says quite clearly on the front "not to be used for identification", you would be right. Maybe.
[brackets in quote from GP are material from GP which was not quoted in parent, but is very relevant]
(1) An SSN is not the same thing as the card, (2) The sense in which GP uses "authentication" is the sense in which the card uses "identification", that is "proof of identity", (3) The sense in which GP uses "identification" apears to be "unambiguous reference to a particular entity", e.g., a primary key in a database.
There is a problem using either a social security card or a social security number for authentication (as GP states), which is also what the card itself disclaims when it says it is not to be used for "identification".
There is very little wrong with using a social security number to identify a person and track records that belong with that person (which is, after all, what the Social Security Administration users them for) -- there are some problems that can crop up that can make it undesirable if you aren't the Social Security Administration, but its not a huge problem in most cases.
The WebDB specification said 'accept the SQL that SQLite accepts'. It was a horrible specification.
That wasn't actually the problem, the absence of the required degree of implementation independence was (at least, in the discussions of the issue, incorporating specifications of the required behavior directly into the standard was, IIRC, specifically called out as an inadequate fix, the problem wasn't the spec per se [that was a problem, but correctable] the problem was the absence of implementations not reliant on SQLite and the absence of interest among browser vendors in making such implementations even if the required behaviors were moved into the spec rather than being defined by reference to SQLite.)
The IETF's requirement, for example, does not require a reference implementation. It requires two independent implementations.
The use of that rule (by people other than IETF) is why we can't have WebDB as a part of the HTML standard: there were several implementations, but all of them left the heavy lifting to the same (public domain) backend (SQLite) rather than reinventing the wheel (or, rather, the lightweight embedded relational database), and so they weren't deemed to be sufficiently independent.
I think you missed the point of the whole "cloud" thing. If you can't get your own "cloud" then it doesn't matter whether the software on the server is open source or not.
If the software is open source, then (presuming it isn't open source software that only runs on very peculiar hardware that isn't generally available on the open market) you can get your own cloud.
That is why, in my opinion, it's so dangerous if governments rely on cloud vendors for their I.T. needs. It's the same as to rely on a proprietary vendor, whether the vendor is using open source software or not.
No, its not. If the vendor hosts the applications, its the same as any other remote application hosting (which existed before the dynamic server provisioning that got dubbed "cloud computing"), but the difference between proprietary and open source platforms is exactly the same with cloud computing as with in-house hosting.
Joe Sixpack is irrelevant to new technology
on
Beyond HDTV
·
· Score: 1
New consumer technology is never aimed at the Joe Sixpack of the time it is released, its an upgrade for Jane Enthusiast.
Joe Sixpack is usually several iterations behind in terms of what they own, and often a couple more in terms of what they are making effective use of.
With a proposed new technology, "Joe Sixpack isn't making effective use of what we have now" isn't really a meaningful criticism. Its almost always true in almost every domain, and it never is more than distantly related to the reason new technologies succeed or fail. Nevertheless, its pretty much guaranteed to be the most common criticism on Slashdot of any new technology.
The real way to tackle this problem is with gas taxes.
If the rational choice model was perfectly accurate representation of human behavior rather than a sometimes useful model with serious problems in certain areas, this would be true; in the real world, because of the way people discount future costs, standards that create immediate incentive to purchase or sell more efficient vehicles are better at improving fleet efficiency than gas taxes, since the future costs represented by gas taxes are discounted when people buy vehicles.
I don't think it is a violation of the GPL before the distributor of the binaries say "No, you can't have it" or fail to deliver within a reasonable timeframe.
Its a violation of the GPL if the distributor of the binaries doesn't either bundle the source code or provide a written offer to provide the source code on request or if, on request, they fail to provide the source code.
So, when they distribute object code and call it source code, and don't accompany it with a written offer to provide the actual source code (and, in fact, conceal that what they have provided is not the actual source code by saying that it is the source code), there is a violation.
The source code is included. Just not the source for the source code.
No, object code is included and the source is not (for the component at issue). The fact that the code is in a format that might be used for other source code (and which needs further compilation to make it executable) doesn't make it source code. The GPL defines "source code" as "the preferred form of the work for making modifications to it", and "object code" as " any non-source form of a work". So, under the GPL, what was distributed as if it was the source code was, in fact, object code.
I was really under the impression that the GPL said you had to distribute the source to anyone you sent the binaries if they actually bothered to request it.
Everyone who has clicked a link to download the thing that calls itself the source tarball has "actually bothered to request" the source code.
What they received was not the entirety of the "source code" as defined in the GPL, which is the whole basis for characterizing this as a GPL violation.
As an anonymous poster above mentioned, I believe it's only a GPL violation if they refused to provide it, right? If no one found out until now, that leads me to believe that no one had asked.
If they have failed to provide it when requested, not "refused", and they have: the thing that is purported to be the complete source code that is available on request is not the complete "source code" as defined in the GPL, so insofar as everyone who has downloaded the thing purporting to be the complete source code has, in sending the download request, requested the source code and as the FSF has failed to deliver the source code in response to those requests, they have failed to provide the source code on request.
Now, because the whole thing builds fine, and its quite likely very few people were concerned about editing the grammar files, its quite likely that people didn't notice that they didn't have the "source code" as defined in the GPL, which is not merely "some files from which the executables can be built", but "the preferred form of the work for making modifications to it."
Slashdot Mirror
It specifies a JavaScript API and a basic end-user interaction model, which isn't part of the WS-* family of standards, and its about a billionth the weight of a web services standard because the actual markup doesn't encode very much at all.
I mean, look at http://webintents.org/
A complete definition of a service (a handler for an intent) is a single tag with three attributes, and other than the (pretty small) JavaScript API, that's all there is to it.
Games, including RPGs, aren't based on pure fantasy. Sure, the setting and story are based on fantasy, but game system designs draws from an evolving palette of tools to achieve the desired ends.
Wait, do you want something where everyone acts like adults and business people?
Or do you want something where everyone resolves their differences without suing everyone and invoking copyrights, trademarks, and patents?
Because, in the real world, "adults and business people" actually are usually the ones using lawsuits invoking copyrights, trademarks, and patents in resolving their differences.
You seem to be describing as the "app market" the "market of things that run software that developers might want to target". While that might be an analytically useful market, its not usually the market iOS to Android comparisons are made in, and it includes as major players things that aren't usually included in iOS vs. Android comparisons (like Windows.)
Though app developers, even on OS's that nominally support a wide range of devices of different form factors, frequently target specific form factors, so I'm not convinced that, even from a developers perspective, even the narrower "mobile app platform" market that includes tablets, phones, and phone-sized-non-phone devices is really a coherent single market.
And aside from form factor, there is also an important distinction for lots of developers between phone and non-phone devices.
The most common comparison I've seen is mobile phone marketshare comparing Android phones (of which there are many) to iPhones (of which there are several models on the market at any one time, not "one single device".)
This isn't the whole universe of Android devices (which include tablets, dual-boot laptops, and I think some dual-boot desktops) against a single iOS device.
What analytically useful market exists that includes iPads, iPods, and the iPhone as part of the same market?
It doesn't. I've seen the kind of brittleness described upthread with every language I've seen development done in, and its been around longer than Java (and, obviously, also .NET) has.
It seems, IME, to be more common on large projects, so its probably more common at any given time in the languages that are used mostly for large enterprise systems.
And even that seems to be overblown over a Windows 8 demo that focussed on the fact that Win8 supports HTML5-based desktop apps, rather than anything concrete. In fact, given the release of Visual Studio Light Switch, I'd say Microsoft is doubling down on Silverlight for line-of-business app development.
Performance of compiled code isn't the only important productivity contributor.
Planning .NET (this isn't specific at all to ASP.NET, so I don't know why you would refer to that) from the outset as a multilanguage VM was a good choice. And I understand the market reasons why VB.NET (to transition VB users -- both desktop and ASP -- onto the platform) and C# (to provide a migration path for Java users) were the choices. And I know why the feature sets of the two languages are so closely aligned. The design decisions make perfect sense if you are Microsoft. They're just a headache if you aren't Microsoft.
I have an aesthetic distaste for VB.NET and wish it would fade over time to reduce unproductive complexity on projects I run into, but I certainly wouldn't say I must kill it off, just that the IT world would be a better place if it were to fade away.
I don't feel superior to people who use VB.NET, I just wish it would go away since it doesn't (unlike F#, IronRuby, IronPython, or any of quite a lot of other languages that run on .NET that aren't C#) have any compelling use case to favor it over C#, but I keep running into environments where the two are mixed with no real rationale for the use of each language. Diversity that adds value is good, diversity that adds support overhead without adding value isn't.
Some of the libraries are locked to a particular OS (or, more commonly, a family of OSs from a particular vendor).
C# has been around with .NET since .NET 1.0 and VB is still going strong. If Microsoft had kept supporting and actively pushed IronRuby and/or IronPython, they might have combined with C# to displace VB.NET
It shouldn't, because while it integrates by default, its trivial to login as any database user from any system account.
No, it doesn't. It is no harder to use different logins for different apps than it is for MySQL. In fact, in most database abstraction libraries, you do it in almost exactly the same way with Postgres as you would with MySQL.
Sure, pg_hba.conf is a strangely-named file, but its well-documented what it is and what its format is and where it is located. More importantly, though, the defaults don't prohibit connections to different DB accounts from the same system account, so you don't actually need to touch it to enable the usage you refer to.
PostgreSQL is, IME, dead simple to use and administer, at least in versions from the last half-decade. Before that it had a possibly-earned reputation for complexity in administration and some issues on Windows particularly, but that's not really the case any more.
Trivial from a technical PoV; communications protocols like PubSubHubbub, and XMPP, and social graph data representations like FOAF and XFN, and authentication protocols like OpenID already support just about all of of what you need to replicate the functions common in modern social networking sites in an open, easily federated network.
Getting the people who have a theoretical interest in such a thing to actually go beyond the technical underpinnings which would allow it to be built and to actually build something on those underpinnings that would be useful to users (individual or institutional) seems to be the biggest problem, not marketing the solutions once they are built.
Google already supports "bazaar"-style social networking (much moreso than does Facebook) via a variety of open APIs for communication and social data and support for open social tagging standards that can be used on any webpage no matter who hosts it that Google will crawl to derive and present social graph data. (OpenSocial API, Social Graph API [which provides access to data that users present on their own pages via XFN or FOAF markup], PubSubHubbub protocol and the open reference hub supporting it, etc., etc., etc., ad nauseum, ad-almost-fricking-infinitum.)
Other than the fact that my Social Security Card says quite clearly on the front "not to be used for identification", you would be right. Maybe.
[brackets in quote from GP are material from GP which was not quoted in parent, but is very relevant]
(1) An SSN is not the same thing as the card,
(2) The sense in which GP uses "authentication" is the sense in which the card uses "identification", that is "proof of identity",
(3) The sense in which GP uses "identification" apears to be "unambiguous reference to a particular entity", e.g., a primary key in a database.
There is a problem using either a social security card or a social security number for authentication (as GP states), which is also what the card itself disclaims when it says it is not to be used for "identification".
There is very little wrong with using a social security number to identify a person and track records that belong with that person (which is, after all, what the Social Security Administration users them for) -- there are some problems that can crop up that can make it undesirable if you aren't the Social Security Administration, but its not a huge problem in most cases.
I never said it wasn't.
That wasn't actually the problem, the absence of the required degree of implementation independence was (at least, in the discussions of the issue, incorporating specifications of the required behavior directly into the standard was, IIRC, specifically called out as an inadequate fix, the problem wasn't the spec per se [that was a problem, but correctable] the problem was the absence of implementations not reliant on SQLite and the absence of interest among browser vendors in making such implementations even if the required behaviors were moved into the spec rather than being defined by reference to SQLite.)
The use of that rule (by people other than IETF) is why we can't have WebDB as a part of the HTML standard: there were several implementations, but all of them left the heavy lifting to the same (public domain) backend (SQLite) rather than reinventing the wheel (or, rather, the lightweight embedded relational database), and so they weren't deemed to be sufficiently independent.
If the software is open source, then (presuming it isn't open source software that only runs on very peculiar hardware that isn't generally available on the open market) you can get your own cloud.
No, its not. If the vendor hosts the applications, its the same as any other remote application hosting (which existed before the dynamic server provisioning that got dubbed "cloud computing"), but the difference between proprietary and open source platforms is exactly the same with cloud computing as with in-house hosting.
New consumer technology is never aimed at the Joe Sixpack of the time it is released, its an upgrade for Jane Enthusiast.
Joe Sixpack is usually several iterations behind in terms of what they own, and often a couple more in terms of what they are making effective use of.
With a proposed new technology, "Joe Sixpack isn't making effective use of what we have now" isn't really a meaningful criticism. Its almost always true in almost every domain, and it never is more than distantly related to the reason new technologies succeed or fail. Nevertheless, its pretty much guaranteed to be the most common criticism on Slashdot of any new technology.
If the rational choice model was perfectly accurate representation of human behavior rather than a sometimes useful model with serious problems in certain areas, this would be true; in the real world, because of the way people discount future costs, standards that create immediate incentive to purchase or sell more efficient vehicles are better at improving fleet efficiency than gas taxes, since the future costs represented by gas taxes are discounted when people buy vehicles.
Its a violation of the GPL if the distributor of the binaries doesn't either bundle the source code or provide a written offer to provide the source code on request or if, on request, they fail to provide the source code.
So, when they distribute object code and call it source code, and don't accompany it with a written offer to provide the actual source code (and, in fact, conceal that what they have provided is not the actual source code by saying that it is the source code), there is a violation.
No, object code is included and the source is not (for the component at issue). The fact that the code is in a format that might be used for other source code (and which needs further compilation to make it executable) doesn't make it source code. The GPL defines "source code" as "the preferred form of the work for making modifications to it", and "object code" as " any non-source form of a work". So, under the GPL, what was distributed as if it was the source code was, in fact, object code.
Everyone who has clicked a link to download the thing that calls itself the source tarball has "actually bothered to request" the source code.
What they received was not the entirety of the "source code" as defined in the GPL, which is the whole basis for characterizing this as a GPL violation.
If they have failed to provide it when requested, not "refused", and they have: the thing that is purported to be the complete source code that is available on request is not the complete "source code" as defined in the GPL, so insofar as everyone who has downloaded the thing purporting to be the complete source code has, in sending the download request, requested the source code and as the FSF has failed to deliver the source code in response to those requests, they have failed to provide the source code on request.
Now, because the whole thing builds fine, and its quite likely very few people were concerned about editing the grammar files, its quite likely that people didn't notice that they didn't have the "source code" as defined in the GPL, which is not merely "some files from which the executables can be built", but "the preferred form of the work for making modifications to it."