Why does Oracle's incompetency and disinterest in Java have to be mutually exclusive propositions?
Of course, for having spent 7.4 billion dollars acquiring Sun, Oracle hasn't put much effort into preseving the value of the assets from that acquisition. Solaris is stagnant, all the Sun efforts to *try* to compete with Linux seem abandoned. Java is a security nightmare on top of being generally despised on end user client platforms. Java's biggest success as a platform has been in Android, and Oracle's response is trying to undermine Google through legal action.
It seems the biggest issue is not Oracle's technical competency or lack thereof, but the business competency certainly seems dubious....
and for some reason car shadows aren't even drawn in first person views
In general, games that do explicitly support 3D often do things like disable shadows and other lighting related things. Those lighting effects are acheived through interesting 'tricks' that end up looking wrong in stereoscopic situation. This wouldn't be a problem for real time ray tracing in theory.
I've seen a lot of small businesses use AD. AD at that scale is *trivial* to 'manage. AD gets pretty hard when you have a large sprawling enterprise with complex organizational structure being modeled in the LDAP tree and a lot of third party 'enterprise' applications that want to use plain-old LDAP to interact with AD, forcing the administrators to understand the LDAP aspect of AD.
That is not how small businesses use AD. They don't know what an OU is because they take the default, they have a single domain without tree of forest. They have no cause to ever see a LDIF or specify a DN for an LDAP entity. They don't have to go through the certificate management required to enable SSL on LDAP. They don't even have to keep in mind the name or address of the domain controller. All they do is take a Windows server, enable AD, and poof, they have a central authentication store only understanding three things: usernames, passwords, and their selected domain name.
One thing MS did absolutely right was to make the very capable and complex AD scale down to trivial configurations really well.
Though I wonder if, given Samba 4.0, FreeIPA is really that critical..
You could either have Samba which can serve a pure Linux environment just fine or even cleanly cope with Windows servers.
On the other hand, FreeIPA can serve a pure Linux environment, perhaps a strict subset of samba capability.
I think FreeIPA was more critically important as it was a faster path to directory based authentication and claimed to be much more production ready than Samba 4.0 claimed to be. I think with Samba 4.0, an inflection point has been reached where there is likely no reason to 'settle' for FreeIPA when Samba may enjoy a superset of capability now...
Simple, if a business has AD infrastructure, AD integration is important. I've seen AD infrastructures in place even in companies of no more than a couple dozen people.
I'm not saying they couldn't have managed without it, but if the powers that be happened to pick AD, then that small business is using AD, whether you think it necessary or not.
We aren't looking for 'is it possible for a small business to avoid AD', we are looking for 'is it true that *currently* AD is not a significant player in small to medium technical businesses?'. The former is undoubtedly true, but the latter is absolutely false.
The rub being that in many of these circumstances, it's one developer's word against anothers in terms of what's more 'maintainable'. In one corner you have a software developer who is a veteran for your company, in another a likely recent college grad still brimming with less-than-practical ideals intact still yet.
If you have a long term codebase that has been managed by people that have come and gone, no rewrite or refactoring should be embarked upon lightly. If the codebase isn't subjecting the business to constant churn and frustration, then no matter how ugly it looks, you don't touch it. Making the case that 'maintenance is expensive on code like what I see' rings hollow when the manager has tracked and knows that his developers haven't been devoting a lot of time to 'maintenance' at all. Just because code is ugly doesn't mean it is not doing the job correctly.
On the other hand, if the codebase is truly a hopeless mess that does have high maintenance cost, then management certainly already feels it. The two parties should be able to recognize the climate and realize which side is in the wrong from a business standpoint. However even here, there is a whole lot of inertia. Even if complete crap that fails a lot and behaves sluggishly and inconsistently, frequently these projects are considered 'sacred cows'. Nothing short of a new project to replace the old would save some of them, and managers recoil in horror at that concept.
Could be they are not specifying an LGA variant of the new design. One notable measure that would make the product inherently hostile to LGA usage would be reducing the redundancy of pins. Gobs of the pins on an LGA Intel socket are redundant grounding pins to make sure that whatever is damaged, it is unlikely to result in a smoke event even if the cpu/board is irreparably damaged in other ways. If Broadwell reduces the footprint and contact point drastically without leaving margin for redundant grounding pins, then LGA may be an unworkable approach from a practical perspective.
Would make more sense to have CPU+Memory cards. Particularly for OEMs in the business of mixing and matching IOH with processor and having to replace boards due to physical damage.
Let me know when they actually solder high pin count BGA connections, that seems unlikely (e.g. the current Ivy Bridge part would mean 1,115 tiny solder points, though it would probably be forgiving and reduced since so many of those pins are ground precisely to tolerate some damaged pins and fail more safely or not fail at all in the event of some damage).
Might actually make more sense to do the converse. With the pin density of a socket, the parts that would make sense would be CPU BGA soldered to a board with DIMMs and PCI-e slots. Active board components like IOH (along with additional PCIe slots it might bring) and damage-prone parts (like the external connectors) would be on a smaller board that could be swapped out and not really have a lot of pins that need to reach the CPU and with less stringent performance restrictions than PCIe and DIMM slot connected components.
Additionally, more difficult to support many combinations of processor+chipset. The upgrade thing for intel has been moot a long time, but the ability to mix and match board and processor model will be greately limited.
It seems at odds with the trend they have had of reducing pin count on cpu package as of late. Maybe they are going to have a behemoth 3,000 pin interconnect which could be a metallurgical nightmare as LGA or something...
This probably also means that the number of models for processor will drastically reduce. If there is only one model of processor, hypothectially, then OEMs don't really have a hard time.
I can't imagine Intel pulling this BGA-only stuff without a portfolio reduction.
The implications for model management mean that, for example, if you want a top end i7 but recognize that the 'business' chipset suffices for IO needs, today you can do that. In the future, even if possible you have to find a board vendor that shared your view, and stuck the top end i7 into a 'low end' chipset. Instead, they'll likely forever marry it only to overpriced chipsets that rarely deliver real value.
I never found the top end cpu part compelling myself, but I can easily see the implications for choice resulting in requiring board manufacturers to pre-integrate.
The obvious question in terms of 'why not just let gnome-shell be tweakable answered with: <quote>We still believe that there should be a single, well-defined UX for GNOME 3, and extensions provide a great mechanism to allow tweaks without giving up on this vision</quote>
I don't understand how this remotely makes sense. I'll preface this by commending the extensible of gnome shell, it allows changes that most other environments cannot offer. However, it's maddening that even the most trivial options mandate extensions to fiddle with. The two sides of the argument are pro-configurability and pro-single UX. What this solution offers is the worst of both worlds. For pro-configurability people, the configuration is not discoverable and its really hard sometimes to find what you want. On top of that, popular extensions break version to version. For pro-single UX people, extensions mean gnome can be anything. This is a single sentence that isn't internally consistent, which can be rephrased as "we don't want configurability because it can create too varied an experience, that's why we think its great that we provide a trivial mechanism that can be used to vary your experience all day long".
I assume the fixation with AD specifically to the point of referencing Samba 4 means Windows will be a way of life.
Once released and incorporated into something like RHEL, then I'd say Samba 4 becomes worthy of consideration. At that point in time:
-If your infrastructure is mostly Windows, stick with AD.
-If your infrastructure/clients is mostly Linux (or clients aren't going to be traditional Windows workstations either way) or you have *realistic* ambitions of this being the case, then Samba 4 will probably be a worthwhile mechanism to integrate and service the occasional Windows presence. Note the realistic aspect of such ambitions cannot be stressed enough. There are a number of pie in the sky plans that everyone who is a part of it *knows* will never happen, and then you'll be stuck with what will be inevitably awkward infrastructure in a windows centric businsess.
While that's true on the hardware side, I think the more important piece is the software design. The console software generally pretty much looks verbatim like the desktop software. Back in the PS2 days and before, I think game companies exercised more discretion and were more conservative about releases (and online multi-player was by and large non-existant). Nowadays they are more aggressive because consoles allow and encourage updating of every little piece of software, and the multi-user facet has now made previously minor bugs major problems (like this case, in a purely single player context, this sort of behavior wouldn't matter at all).
I know on PS3, if I pop in a game I haven't played in a month or two, there is almost *certainly* going to be a mandatory update to apply before the PS3 will even let me play it single player.
In this case, Valve's agenda is the lesser of two evils. Either MS gets their way and Linux desktops continue with the relatively sparse gaming library compared to Windows systems, or Valve gets their way and at least Linux gets a lot of the titles that were formerly Windows-only.
I'd rather a viable company scheme be one that operates within the structure of the general structure of Linux based desktops than requiring Windows or wine. Purists can still run their desktop with the same (or even better) selection of truly free software, and the rest of us can use a free desktop without compromising or dual boot to get at a few titles we really would enjoy.
I see two possibliities: MS is sufficiently deluded that they genuinely think doubling down on Silverlight based technology while forcing tighter lockin to MS store and services is going to work and lead to rapid obsolecence of their existing software ecosystem without anything of significance lost. This seems to fly against all evidence and reason, but I wouldn't put it past them.
The other possibility is that WindowsRT isn't *that* serious an endeavor. Enough invested to make it *real* and maybe even take off in the unlikely scenario described above. Not enough to actually enable the large third-party application base that remains MS' sole meaningful advantage nowadays. The hope may be to scare AMD and Intel to worry more and work harder to provide compelling x86 compatible solutions amenable to the same physical form factors that are being popularized in iOS and Android devices. The strongest evidence of this that I can see is how both AMD and Intel have pretty much explicitly come out and said their next big thing in the mobile space is very much designed exclusively for Windows usage. Linux (notably Android) have been de-emphasized by both Intel and AMD for those chips as they go out of their way to endorse Windows 8. This could either be due to pressure/threats from MS but it also might be explained by Intel's relative failure to attract real partnerships in the Android space despite an earnest effort to do so, which would drive both AMD and Intel to realize that they really need microsoft to retain competitive advantage over non-x86 architectures.
On the other hand, the only thing I use with my Android phone that was in the box is the phone itself, I haven't had to keep track of any cables or adapters.
For the removable battery, it isn't as much about the ability to swap batteries for more charge, it's about being able to cheaply replace the battery when it no longer reliably holds a charge (batteries have improved a lot, but it is still generally the first component to fail in an otherwise serviceable mobile device).
Fast forward 2 years, and Apple just abrogates the entire agreement because their engineers are too dumb to figure out what every other phone manufacturer has already figured out.
It almost certainly isn't because their engineers are inept, it is almost certainly because Apple executives want to enrich the dock accessory royalty revenue and keep an iron grip on customers. The moment Apple makes it easy to acheive functionality through standards (e.g. USB standard devices), a revenue stream dries up and lockin is reduced.
Switching to just a micro-USB would have been stupid as you can't get analog audio or HD video through USB 2.0. Still I feel for all the people who've invested in accessories that use the standar Apple 30-pin. Expensive accessories like docks, iHome clocks, etc.
Actually, the new dock connector is said to eliminate analog audio anyway, so that's BS. Second, for USB speed, nothing says it can't be USB 3.0. Third, that's all a moot point to video, MHL devices do HDMI out out of a physical port that is micro usb compatible. In most cases, using the same pins as USB, but in the case of Galaxy S 3, through 6 additional pins that are accomodated without breaking micro usb mechanical compatibility.
Apple's use of a proprietary connector is exactly because of one reason: because they can get away with it. It's part of their business plan, plain and simple. When they sell an iDevice, they don't take a loss, but they also endeavor to maximize ongoing revenue potential. One mechanism is by using a proprietary connector and forcing third party accessories to pay a license fee for the privilege of supporting iDevices. Bonus: vendors largely end up ignoring Android compatibility since they have to pick *either* Apple or other devices if they can only afford one device.
Once it became dual licensed, the reason to have a GNOME was no longer there.
Actually, at the time it was GPL and Commercial. RMS might have been satisfied with GPL (I really didn't pay attention), but there was definitely a camp of people that felt that LGPL was the correct choice. *Now* LGPL is also permissable. There is still a contingent feeling that requiring C++ is too onerous though.
If they really wanted to do a GNU Networked Object Model Environment, they should have taken GNUSTEP, studied it and modified it to suit whatever their idea of a networked OO interface was.
Yeah, that had some peculiar concept with no viable demonstration. Despite being baked into the name, it looks like the concept was ultimately scrapped as not being particularly relevant. I too wish GNUstep received a bit more attention. I had high hopes when OSX was embracing the NeXT pieces that the community might have said 'maybe we should pay attention to this GNUstep effort', but it's still so neglected. I should try etoile, though at the time I was left wondering 'why not windowmaker' for the effort.
Slashdot Mirror
Why does Oracle's incompetency and disinterest in Java have to be mutually exclusive propositions?
Of course, for having spent 7.4 billion dollars acquiring Sun, Oracle hasn't put much effort into preseving the value of the assets from that acquisition. Solaris is stagnant, all the Sun efforts to *try* to compete with Linux seem abandoned. Java is a security nightmare on top of being generally despised on end user client platforms. Java's biggest success as a platform has been in Android, and Oracle's response is trying to undermine Google through legal action.
It seems the biggest issue is not Oracle's technical competency or lack thereof, but the business competency certainly seems dubious....
and for some reason car shadows aren't even drawn in first person views
In general, games that do explicitly support 3D often do things like disable shadows and other lighting related things. Those lighting effects are acheived through interesting 'tricks' that end up looking wrong in stereoscopic situation. This wouldn't be a problem for real time ray tracing in theory.
I've seen a lot of small businesses use AD. AD at that scale is *trivial* to 'manage. AD gets pretty hard when you have a large sprawling enterprise with complex organizational structure being modeled in the LDAP tree and a lot of third party 'enterprise' applications that want to use plain-old LDAP to interact with AD, forcing the administrators to understand the LDAP aspect of AD.
That is not how small businesses use AD. They don't know what an OU is because they take the default, they have a single domain without tree of forest. They have no cause to ever see a LDIF or specify a DN for an LDAP entity. They don't have to go through the certificate management required to enable SSL on LDAP. They don't even have to keep in mind the name or address of the domain controller. All they do is take a Windows server, enable AD, and poof, they have a central authentication store only understanding three things: usernames, passwords, and their selected domain name.
One thing MS did absolutely right was to make the very capable and complex AD scale down to trivial configurations really well.
Though I wonder if, given Samba 4.0, FreeIPA is really that critical..
You could either have Samba which can serve a pure Linux environment just fine or even cleanly cope with Windows servers.
On the other hand, FreeIPA can serve a pure Linux environment, perhaps a strict subset of samba capability.
I think FreeIPA was more critically important as it was a faster path to directory based authentication and claimed to be much more production ready than Samba 4.0 claimed to be. I think with Samba 4.0, an inflection point has been reached where there is likely no reason to 'settle' for FreeIPA when Samba may enjoy a superset of capability now...
Simple, if a business has AD infrastructure, AD integration is important. I've seen AD infrastructures in place even in companies of no more than a couple dozen people.
I'm not saying they couldn't have managed without it, but if the powers that be happened to pick AD, then that small business is using AD, whether you think it necessary or not.
We aren't looking for 'is it possible for a small business to avoid AD', we are looking for 'is it true that *currently* AD is not a significant player in small to medium technical businesses?'. The former is undoubtedly true, but the latter is absolutely false.
The rub being that in many of these circumstances, it's one developer's word against anothers in terms of what's more 'maintainable'. In one corner you have a software developer who is a veteran for your company, in another a likely recent college grad still brimming with less-than-practical ideals intact still yet.
If you have a long term codebase that has been managed by people that have come and gone, no rewrite or refactoring should be embarked upon lightly. If the codebase isn't subjecting the business to constant churn and frustration, then no matter how ugly it looks, you don't touch it. Making the case that 'maintenance is expensive on code like what I see' rings hollow when the manager has tracked and knows that his developers haven't been devoting a lot of time to 'maintenance' at all. Just because code is ugly doesn't mean it is not doing the job correctly.
On the other hand, if the codebase is truly a hopeless mess that does have high maintenance cost, then management certainly already feels it. The two parties should be able to recognize the climate and realize which side is in the wrong from a business standpoint. However even here, there is a whole lot of inertia. Even if complete crap that fails a lot and behaves sluggishly and inconsistently, frequently these projects are considered 'sacred cows'. Nothing short of a new project to replace the old would save some of them, and managers recoil in horror at that concept.
Could be they are not specifying an LGA variant of the new design. One notable measure that would make the product inherently hostile to LGA usage would be reducing the redundancy of pins. Gobs of the pins on an LGA Intel socket are redundant grounding pins to make sure that whatever is damaged, it is unlikely to result in a smoke event even if the cpu/board is irreparably damaged in other ways. If Broadwell reduces the footprint and contact point drastically without leaving margin for redundant grounding pins, then LGA may be an unworkable approach from a practical perspective.
Would make more sense to have CPU+Memory cards. Particularly for OEMs in the business of mixing and matching IOH with processor and having to replace boards due to physical damage.
Let me know when they actually solder high pin count BGA connections, that seems unlikely (e.g. the current Ivy Bridge part would mean 1,115 tiny solder points, though it would probably be forgiving and reduced since so many of those pins are ground precisely to tolerate some damaged pins and fail more safely or not fail at all in the event of some damage).
Or Intel will only offer 2 or 3 models instead of the current diverse lineup...
Might actually make more sense to do the converse. With the pin density of a socket, the parts that would make sense would be CPU BGA soldered to a board with DIMMs and PCI-e slots. Active board components like IOH (along with additional PCIe slots it might bring) and damage-prone parts (like the external connectors) would be on a smaller board that could be swapped out and not really have a lot of pins that need to reach the CPU and with less stringent performance restrictions than PCIe and DIMM slot connected components.
Additionally, more difficult to support many combinations of processor+chipset. The upgrade thing for intel has been moot a long time, but the ability to mix and match board and processor model will be greately limited.
It seems at odds with the trend they have had of reducing pin count on cpu package as of late. Maybe they are going to have a behemoth 3,000 pin interconnect which could be a metallurgical nightmare as LGA or something...
This probably also means that the number of models for processor will drastically reduce. If there is only one model of processor, hypothectially, then OEMs don't really have a hard time.
I can't imagine Intel pulling this BGA-only stuff without a portfolio reduction.
The implications for model management mean that, for example, if you want a top end i7 but recognize that the 'business' chipset suffices for IO needs, today you can do that. In the future, even if possible you have to find a board vendor that shared your view, and stuck the top end i7 into a 'low end' chipset. Instead, they'll likely forever marry it only to overpriced chipsets that rarely deliver real value.
I never found the top end cpu part compelling myself, but I can easily see the implications for choice resulting in requiring board manufacturers to pre-integrate.
The obvious question in terms of 'why not just let gnome-shell be tweakable answered with:
<quote>We still believe that there should be a single, well-defined UX for
GNOME 3, and extensions provide a great mechanism to allow tweaks
without giving up on this vision</quote>
I don't understand how this remotely makes sense. I'll preface this by commending the extensible of gnome shell, it allows changes that most other environments cannot offer. However, it's maddening that even the most trivial options mandate extensions to fiddle with. The two sides of the argument are pro-configurability and pro-single UX. What this solution offers is the worst of both worlds. For pro-configurability people, the configuration is not discoverable and its really hard sometimes to find what you want. On top of that, popular extensions break version to version. For pro-single UX people, extensions mean gnome can be anything. This is a single sentence that isn't internally consistent, which can be rephrased as "we don't want configurability because it can create too varied an experience, that's why we think its great that we provide a trivial mechanism that can be used to vary your experience all day long".
Actually has 2 *weeks* of fuel supply (huge diesel tanks).
I assume the fixation with AD specifically to the point of referencing Samba 4 means Windows will be a way of life.
Once released and incorporated into something like RHEL, then I'd say Samba 4 becomes worthy of consideration. At that point in time:
-If your infrastructure is mostly Windows, stick with AD.
-If your infrastructure/clients is mostly Linux (or clients aren't going to be traditional Windows workstations either way) or you have *realistic* ambitions of this being the case, then Samba 4 will probably be a worthwhile mechanism to integrate and service the occasional Windows presence. Note the realistic aspect of such ambitions cannot be stressed enough. There are a number of pie in the sky plans that everyone who is a part of it *knows* will never happen, and then you'll be stuck with what will be inevitably awkward infrastructure in a windows centric businsess.
While that's true on the hardware side, I think the more important piece is the software design. The console software generally pretty much looks verbatim like the desktop software. Back in the PS2 days and before, I think game companies exercised more discretion and were more conservative about releases (and online multi-player was by and large non-existant). Nowadays they are more aggressive because consoles allow and encourage updating of every little piece of software, and the multi-user facet has now made previously minor bugs major problems (like this case, in a purely single player context, this sort of behavior wouldn't matter at all).
I know on PS3, if I pop in a game I haven't played in a month or two, there is almost *certainly* going to be a mandatory update to apply before the PS3 will even let me play it single player.
In this case, Valve's agenda is the lesser of two evils. Either MS gets their way and Linux desktops continue with the relatively sparse gaming library compared to Windows systems, or Valve gets their way and at least Linux gets a lot of the titles that were formerly Windows-only.
I'd rather a viable company scheme be one that operates within the structure of the general structure of Linux based desktops than requiring Windows or wine. Purists can still run their desktop with the same (or even better) selection of truly free software, and the rest of us can use a free desktop without compromising or dual boot to get at a few titles we really would enjoy.
I see two possibliities:
MS is sufficiently deluded that they genuinely think doubling down on Silverlight based technology while forcing tighter lockin to MS store and services is going to work and lead to rapid obsolecence of their existing software ecosystem without anything of significance lost. This seems to fly against all evidence and reason, but I wouldn't put it past them.
The other possibility is that WindowsRT isn't *that* serious an endeavor. Enough invested to make it *real* and maybe even take off in the unlikely scenario described above. Not enough to actually enable the large third-party application base that remains MS' sole meaningful advantage nowadays. The hope may be to scare AMD and Intel to worry more and work harder to provide compelling x86 compatible solutions amenable to the same physical form factors that are being popularized in iOS and Android devices. The strongest evidence of this that I can see is how both AMD and Intel have pretty much explicitly come out and said their next big thing in the mobile space is very much designed exclusively for Windows usage. Linux (notably Android) have been de-emphasized by both Intel and AMD for those chips as they go out of their way to endorse Windows 8. This could either be due to pressure/threats from MS but it also might be explained by Intel's relative failure to attract real partnerships in the Android space despite an earnest effort to do so, which would drive both AMD and Intel to realize that they really need microsoft to retain competitive advantage over non-x86 architectures.
Well, Samsung's 11 pin MHL will work (though the stance that MHL doesn't require a particular connector certainly weakens its value as a standard).
On the other hand, the only thing I use with my Android phone that was in the box is the phone itself, I haven't had to keep track of any cables or adapters.
For the removable battery, it isn't as much about the ability to swap batteries for more charge, it's about being able to cheaply replace the battery when it no longer reliably holds a charge (batteries have improved a lot, but it is still generally the first component to fail in an otherwise serviceable mobile device).
Fast forward 2 years, and Apple just abrogates the entire agreement because their engineers are too dumb to figure out what every other phone manufacturer has already figured out.
It almost certainly isn't because their engineers are inept, it is almost certainly because Apple executives want to enrich the dock accessory royalty revenue and keep an iron grip on customers. The moment Apple makes it easy to acheive functionality through standards (e.g. USB standard devices), a revenue stream dries up and lockin is reduced.
Switching to just a micro-USB would have been stupid as you can't get analog audio or HD video through USB 2.0. Still I feel for all the people who've invested in accessories that use the standar Apple 30-pin. Expensive accessories like docks, iHome clocks, etc.
Actually, the new dock connector is said to eliminate analog audio anyway, so that's BS. Second, for USB speed, nothing says it can't be USB 3.0. Third, that's all a moot point to video, MHL devices do HDMI out out of a physical port that is micro usb compatible. In most cases, using the same pins as USB, but in the case of Galaxy S 3, through 6 additional pins that are accomodated without breaking micro usb mechanical compatibility.
Apple's use of a proprietary connector is exactly because of one reason: because they can get away with it. It's part of their business plan, plain and simple. When they sell an iDevice, they don't take a loss, but they also endeavor to maximize ongoing revenue potential. One mechanism is by using a proprietary connector and forcing third party accessories to pay a license fee for the privilege of supporting iDevices. Bonus: vendors largely end up ignoring Android compatibility since they have to pick *either* Apple or other devices if they can only afford one device.
It's a very anti-consumer move, plain and simple.
Once it became dual licensed, the reason to have a GNOME was no longer there.
Actually, at the time it was GPL and Commercial. RMS might have been satisfied with GPL (I really didn't pay attention), but there was definitely a camp of people that felt that LGPL was the correct choice. *Now* LGPL is also permissable. There is still a contingent feeling that requiring C++ is too onerous though.
If they really wanted to do a GNU Networked Object Model Environment, they should have taken GNUSTEP, studied it and modified it to suit whatever their idea of a networked OO interface was.
Yeah, that had some peculiar concept with no viable demonstration. Despite being baked into the name, it looks like the concept was ultimately scrapped as not being particularly relevant. I too wish GNUstep received a bit more attention. I had high hopes when OSX was embracing the NeXT pieces that the community might have said 'maybe we should pay attention to this GNUstep effort', but it's still so neglected. I should try etoile, though at the time I was left wondering 'why not windowmaker' for the effort.