Please give some in-depth information about the relative market share of System76 compared to HP or Dell's consumer hardware.
I don't have that information, sorry. I don't even know how to get those numbers for HP or Dell. But if I had to guess, they're probably don't even have a full digit penetration outside of geek circles.
whether they sell through retail channels like Best Buy?
No idea, about the US, but 'Idea' in Poland sold some System76, which is how I first learned of them.
I support Linux as much as the next FOSS enthusiast
I'm not a FOSS enthusiast.
there will NEVER be a Year of the Linux Desktop.
That's not something I'm trying to promote or work towards either.
Can he do anything even at the same level as a child of the same age in 1950?
No offense, but I'm not impressed with a lot of people who were educated in any year so far. If people educated in the 1950s had much to offer, we'd notice it in them as adults.
I'm going to note that the majority of those applications/DEs exist on Windows too (I've ran older versions of Gnome on Windows numerous times), I'm not understanding how this is a Linux specific issue? If it was Linux specific, then surely Gnome on Windows would have been using COM.
GNOME: GObject. Still the official standard, based on C and now "Vala", no persistence, no remoting, several iterations of failed C++ wrappers GNOME: Bonobo. Based on CORBA for remoting, but used its own funky CORBA implementation, very quickly abandoned KDE: Qt. C++ library which ate the whole desktop, requires its own preprocessor for its own "extended" obejct model, so not quite pure C++. No persistence. KDE: KParts. Object model on top of Qt's special sauce. I think it's still there in the architecture? KDE: DCOP. Object model on top of Qt's special sauce. I think deprecated now in favour of D-bus?.....
You do know you can access a good chunk of those through dbus as long as you install the correct dbus library, like dbus-glib for GObjects, the major stuff in DEs generally has backwards compatible options I find.
Oh, but that's not all. We've also got various flavours of semi-official languages at the application and system level with their OWN object models, most of which live in only the one running process and evaporate when runtime ends. Mostly.
Again, same issue on Windows. One of the applications I do development on, communicates with a binary blob voice chat system provided by Vivox technologies, the only way to communicate with said application is via anonymous pipes instead of com on Windows, and I have no ability to use com instead if I wanted. But hey, I've also got an application on Windows that still makes use of DDE to provide music information, not com, I can't even access DDE from com. At least d-bus offers some sort of backwards/forwards compatibility here.
Linux has failed pretty badly here, and sometimes I think application developers are the worst at realising the extent of the failure. "It works for ME!" they say, not realising that it only works because they've confined themselves to a single build-compile-run environment based on shipping "their project", and walled themselves off from the rest of the distribution-wide ecosystem.
I'm doing what you're saying, taking the whole ecosystem into account now. Even the Windows' ecosystem won't deal with specific implementations that do other things any better.
You do realize if you use distributions like SUSE, Ubuntu, Redhat etc. the kernel ABI does not change in kernel updates? The only time you will see a change is when a new distribution version is released. This isn't much different from the various ABI changes that Windows recieves when they release major versions.
I've found my workstation development abilities translate absolutely fine to an iPad with an SSH client to the workstation, bluetooth keyboard and using my usual development tools (I haven't quite decided if I prefer vim or emacs yet). Screen wise, my iPad actually offers a bigger screen and higher resolution than my current laptop and a better battery life.
When do I use my iPad for doing developmental things? For my pet projects when I'm in hotels, visiting a friend randomly or some random lobby.
Wow... Your argument is essentially storage capacity and support for specific types of removable media. You realize you've kind of just hinted that iPad is fairly usable to people who can make use of 64GB space or has decent access to iCloud (as you imply that's a viable alternative if you don't have connectivity issues). Also, I can easily resolve your capacity problem with bluetooth storage devices.
Personally, I think there are numerous other things iOS needs to be a native development environment. I do use my iPad on occasion for development, paticularly when away from home to work on pet projects, but that's really me working on a SSH client that is connected to my workstation, while using a bluetooth keyboard with my iPad. I can't see my self switching to a native environment, the mature toolchain I have on my Linux development environments is not likely to be an easy task to port over and ignoring porting issues, doing something that fits well with both touchscreen and keyboard interface seems fairly difficult to do 'right' from my perspective.
I'm not an Apple fan, but I will admit, I used my iPad for development for a while when my laptop wouldn't do - it didn't have the battery life. My iPad case has an integrated bluetooth keyboard that is paired with it. I was able to SSH into my workstation remotely and do development normally for many hours.
I've done a little development using my iPad remotely. I SSHed into my workstation and continued development as I usually would normally in the terminal. I do have a case with an integrated bluetooth keyboard for my iPad though. If I only had the touchscreen, that would be fairly assinine.
I have a case that has an integrated bluetooth keyboard for my iPad. I find it fairly decent to type with for hours on end - I generally use it for messaging, posting messages on websites etc.
exactly. whereas COM has basically never changed (not at a fundamental level) since it was first deployed eek 2 decades ago. every COM object is self-describing so its functions can be enumerated. the OLE concept goes even further: there are standard interfaces (e.g. "GetData" which, surprisingly, allows you to gain access to the data of the object, and *that* is a self-describing, self-documenting interface as well)
Is this meant to matter when you still can't run the applications anyway as in the situation my quotation was about?
Or the fact that you can't have multiple versions of related software installed because you could only have one COM registered, then the workaround being a manifest file which really only helps if you did it right at compile time? (hint: Few developers ever test this)
then also COM and other COM-like systems make it *easy* to create backwards-compatible interface versioning, and, as a general rule, once one set of examples gets out there (and the MSIE IDL files are the absolute classic example) then even the most noddy programmers tend to follow suit and stick with the same practice.
Except in my other examples, I have shown modern applications communicating with old ones just fine on Linux, without any modifications on my end at all. I'd say that's pretty easy - it just requires development of the particular applications done correctly, just like on windows - I would say it's easier since it's just using sane name spaces as opposed to goofy manifest files.
the point is that both the discipline and the easy-to-use core technology are both entirely missing from the linux community.
If by discipline you mean developers doing the correct thing, then I've seen far too much shit on to believe this is common on Windows. See issues with manifest files and reregistration of components with older libraries that don't work with newer applications - versioning did nothing for it. Amazingly, if Windows developers had followed saner versioning schemes like library versions being apart of the namespace, these issues could have been avoided, even by Microsoft's own conflicts instead of inventing an even more convoluted system with manifest files.
As for 'easy-to-use core technology', I don't think you can get anything more basic as 'file sockets', sane namespaces, if you want dumb, easy technology. Or escalate up with higher level libraries that make use of x11, dbus etc.
because adding COM-like systems into kernels
It doesn't really matter if it's userland or kernel at the end of the day. If it did, Windows wouldn't be in a better position since it uses services to segregate that functionality outside of the kernel.
he pointed out that there seems to be a general ethos to follow "the leaders" such as linus torvalds, who right or wrong do *not* support the concept of binary backwards-compatibility
Honestly, I think you're mixing arguments here, binary compatibility in the kernel is different from the userland. Linux applications tend to be written against the userland libc, not the kernel. For this reason, I can get ancient userland applications running just fine by copying the old libc those applications are dependent on (if they're not statically linked - statically linked wise means they have no dependencies and should 'just work') and and other dependencies.. Prestro, they work. And usually for the most part it won't be conflicting with the rest of the system as long as the name spaces of the libraries it depends on doesn't conflict with the existing user space... But even if it did, ld_preloadpath and fakeroot are fairly quick workarounds for it.
Compare with Windows (and I'll even ignore 16bit applications this time) where you still have some absurd applications that depend on windows 3 APIs which were used in some 32bit applications since Microsoft di
Actually, if you use mingw on Windows, you don't need to worry about the Windows way of doing things. Also, using a common toolkit available between both platforms such as Qt would help with GUI issues.
I'd like an OS that doesn't upgrade at all (except security fixes), so I know my software will still work today in 2012, or in the future in 2020.
You can buy Redhat support and keep running the same distribution version for thirteen years without upgrading - You will receive security updates for the time you remain subscribed to Redhat's support.
There, I solved your requirements, now you can't complain anymore.
Do you even have a credible source to back that up? Our minimum wages in the UK have been increasing, which seems to counter the implication of slave labor type situations.
I'm often dismayed by the piece of crap art that is sold for stupid amounts of money (at least four digits) while some of the most beautiful art is often available in two digits. Then again, I shouldn't complain too loudly, because I wouldn't be able to afford it then.
Slashdot Mirror
I don't have that information, sorry. I don't even know how to get those numbers for HP or Dell. But if I had to guess, they're probably don't even have a full digit penetration outside of geek circles.
No idea, about the US, but 'Idea' in Poland sold some System76, which is how I first learned of them.
I'm not a FOSS enthusiast.
That's not something I'm trying to promote or work towards either.
No offense, but I'm not impressed with a lot of people who were educated in any year so far. If people educated in the 1950s had much to offer, we'd notice it in them as adults.
I'm going to note that the majority of those applications/DEs exist on Windows too (I've ran older versions of Gnome on Windows numerous times), I'm not understanding how this is a Linux specific issue? If it was Linux specific, then surely Gnome on Windows would have been using COM.
You do know you can access a good chunk of those through dbus as long as you install the correct dbus library, like dbus-glib for GObjects, the major stuff in DEs generally has backwards compatible options I find.
Again, same issue on Windows. One of the applications I do development on, communicates with a binary blob voice chat system provided by Vivox technologies, the only way to communicate with said application is via anonymous pipes instead of com on Windows, and I have no ability to use com instead if I wanted. But hey, I've also got an application on Windows that still makes use of DDE to provide music information, not com, I can't even access DDE from com. At least d-bus offers some sort of backwards/forwards compatibility here.
I'm doing what you're saying, taking the whole ecosystem into account now. Even the Windows' ecosystem won't deal with specific implementations that do other things any better.
Please give some in depth information about how Linux does not "just run" on systems like http://system76.com/
Thanks.
Can you show me the source of information that told you they reused code, please? Thanks.
You do realize if you use distributions like SUSE, Ubuntu, Redhat etc. the kernel ABI does not change in kernel updates? The only time you will see a change is when a new distribution version is released. This isn't much different from the various ABI changes that Windows recieves when they release major versions.
Windows has a POSIX subsystem which actually behaves more correctly to specification than OS X's does.
I've found my workstation development abilities translate absolutely fine to an iPad with an SSH client to the workstation, bluetooth keyboard and using my usual development tools (I haven't quite decided if I prefer vim or emacs yet). Screen wise, my iPad actually offers a bigger screen and higher resolution than my current laptop and a better battery life.
When do I use my iPad for doing developmental things? For my pet projects when I'm in hotels, visiting a friend randomly or some random lobby.
I do develop hobby software projects when mobile, like, at hotels, visiting a friend, sitting in a random a lobby. But on a bus? What.
Wow... Your argument is essentially storage capacity and support for specific types of removable media. You realize you've kind of just hinted that iPad is fairly usable to people who can make use of 64GB space or has decent access to iCloud (as you imply that's a viable alternative if you don't have connectivity issues). Also, I can easily resolve your capacity problem with bluetooth storage devices.
Personally, I think there are numerous other things iOS needs to be a native development environment. I do use my iPad on occasion for development, paticularly when away from home to work on pet projects, but that's really me working on a SSH client that is connected to my workstation, while using a bluetooth keyboard with my iPad. I can't see my self switching to a native environment, the mature toolchain I have on my Linux development environments is not likely to be an easy task to port over and ignoring porting issues, doing something that fits well with both touchscreen and keyboard interface seems fairly difficult to do 'right' from my perspective.
I'm not an Apple fan, but I will admit, I used my iPad for development for a while when my laptop wouldn't do - it didn't have the battery life. My iPad case has an integrated bluetooth keyboard that is paired with it. I was able to SSH into my workstation remotely and do development normally for many hours.
I've done a little development using my iPad remotely. I SSHed into my workstation and continued development as I usually would normally in the terminal. I do have a case with an integrated bluetooth keyboard for my iPad though. If I only had the touchscreen, that would be fairly assinine.
I have a case that has an integrated bluetooth keyboard for my iPad. I find it fairly decent to type with for hours on end - I generally use it for messaging, posting messages on websites etc.
I use a bluetooth keyboard with my iPad just fine?
I use it heavilly for messaging, so I don't end up using the touchscreen much.
Doesn't that require installing Java first?
Hit the 'home screen' key twice.
I use a bluetooth keyboard with my iPad, I'm not really seeing the usability issue?
Is this meant to matter when you still can't run the applications anyway as in the situation my quotation was about?
Or the fact that you can't have multiple versions of related software installed because you could only have one COM registered, then the workaround being a manifest file which really only helps if you did it right at compile time? (hint: Few developers ever test this)
Except in my other examples, I have shown modern applications communicating with old ones just fine on Linux, without any modifications on my end at all. I'd say that's pretty easy - it just requires development of the particular applications done correctly, just like on windows - I would say it's easier since it's just using sane name spaces as opposed to goofy manifest files.
If by discipline you mean developers doing the correct thing, then I've seen far too much shit on to believe this is common on Windows. See issues with manifest files and reregistration of components with older libraries that don't work with newer applications - versioning did nothing for it. Amazingly, if Windows developers had followed saner versioning schemes like library versions being apart of the namespace, these issues could have been avoided, even by Microsoft's own conflicts instead of inventing an even more convoluted system with manifest files.
As for 'easy-to-use core technology', I don't think you can get anything more basic as 'file sockets', sane namespaces, if you want dumb, easy technology. Or escalate up with higher level libraries that make use of x11, dbus etc.
It doesn't really matter if it's userland or kernel at the end of the day. If it did, Windows wouldn't be in a better position since it uses services to segregate that functionality outside of the kernel.
Honestly, I think you're mixing arguments here, binary compatibility in the kernel is different from the userland. Linux applications tend to be written against the userland libc, not the kernel. For this reason, I can get ancient userland applications running just fine by copying the old libc those applications are dependent on (if they're not statically linked - statically linked wise means they have no dependencies and should 'just work') and and other dependencies.. Prestro, they work. And usually for the most part it won't be conflicting with the rest of the system as long as the name spaces of the libraries it depends on doesn't conflict with the existing user space... But even if it did, ld_preloadpath and fakeroot are fairly quick workarounds for it.
Compare with Windows (and I'll even ignore 16bit applications this time) where you still have some absurd applications that depend on windows 3 APIs which were used in some 32bit applications since Microsoft di
Maybe next time by your laptop from a vendor like System76?
I don't understand, how does that apply to both the UK and US simultaneously?
Actually, if you use mingw on Windows, you don't need to worry about the Windows way of doing things. Also, using a common toolkit available between both platforms such as Qt would help with GUI issues.
You can buy Redhat support and keep running the same distribution version for thirteen years without upgrading - You will receive security updates for the time you remain subscribed to Redhat's support.
There, I solved your requirements, now you can't complain anymore.
You ruined my stage, this would have been so hilarious. :(
Do you even have a credible source to back that up? Our minimum wages in the UK have been increasing, which seems to counter the implication of slave labor type situations.
Curl is not usually available on older UNIX systems. Also, I haven't verified in years whether or not Slashdot still produces those headers.
I'm often dismayed by the piece of crap art that is sold for stupid amounts of money (at least four digits) while some of the most beautiful art is often available in two digits. Then again, I shouldn't complain too loudly, because I wouldn't be able to afford it then.