This part kind of aggravates me, honestly. There's a chicken-and-egg problem when it comes to diddling with every relevant part of the stack and how they communicate with the driver layers. The most important part as far as maintaining compatibility and supporting existing systems is making it so that common (legacy is the wrong word) API layers continue to function utilizing the new back-ends, but the logistics of where that begins and ends are very much in flux with this development process. OpenGL is a natural, obvious solution with regard to 'language we use to draw to the display', but how OpenGL is implemented is very much in question with this process.
Hardware failure can't be avoided, but I think we can do better on the software side of things. I mean, if the Wayland project keeps going strong and the efforts to Not Break Everything keep progressing, we could end up with a case where X.org simply has a Wayland driver and while all the issues that can exist may exist, we can bypass a lot of the heartache if the project continues going smoothly. This article gives me hope that we're not destroying everything in this process.
After all of the bitcoins are mined, there is no longer an incentive to treat it in this goldrush-like manner. The only people who will have reason to run a miner are the people who use bitcoins as a currency, to be a node in their decentralized economy. Most of the problems people describe seem to be directly related to its use as a pump and dump, actually. I must wonder what's going to happen once we reach that point.
Fact is that I can remotely control almost any computer running on almost any platform utilizing countless different variations of the theme of 'render to the display - wait, let's render to an image instead then send it over the wire'
The reason so much attention is being put on display servers is as a distraction from the real problems, such as the fact that so much attention is being put on the display servers. They're not the weak point, there are a lot of them, and one exercise that remains THROUGHOUT COMPUTING HISTORY, is the task of updating software and porting it to another display server, because at the end of the day you're drawing colored rectangles on a screen.
The line between amateur and professional is one that is heavily drawn and maintained by a certain class of 'professionals'. It doesn't really matter what industry we're talking about on that one, what matters is the resources behind the individual worker. You create professionals by giving amateurs the resources they need to do their job efficiently and with high quality and by being able to provide them the wisdom (from honest professionals, not 'professional' professionals) they need to understand what mistakes they're making and how to solve them. A real journalist is defined by practicing journalism, and the content received from journalist-on-the-street is going to be more raw and real than the content coming from the professional. This might make the street journalist's word infinitely more valuable than the professional journalist's word, depending on whether the professional journalist is actually a journalist or just a professional.
The points you mention are the reason why I advocate the use of tabs rather than spaces. I kinda feel like the guys who use spaces don't actually understand what they're doing when they indent, especially if they can't decide how many spaces an indent should be. Tab. One character. Indent.
Intel has decent enough open source drivers, until you get to the chips like the GMA 500 that just don't quite DO that. Intel has done pretty good with Linux support overall, but they definitely haven't solved the problem.
I love the wide range of places that vi has ended up... I feel like we really need to go retrograde to have honest software innovation at this point, I like the idea of using a modern web browser to re-implement something like MobaXterm (it's a slick cyg/mingw terminal emulator package for Windows) and then using classical foundation technologies as the classical foundation on all these devices. The old unix philosophy of having the utilities do what they do well combined with the technology to put a shiny and solid interface on it.
But, even on my triple GHz quad-core workstation with 8 gigs of RAM, I can feel the drag of so many layers of abstraction when I'm playing with these web technologies that I suggested. Native application performance is truly unmatched and it doesn't have anything to do with how well put together these web applications are, the sandboxes just have too much baggage even with all the JIT tricks they're trying to pull these days.
'Rebuilding Vim for the 21st Century' says it all. The problem with the 21st century from what I've seen, is this insistence that we must re-invent the ENTIRE wheel.
I'm going to suggest that if you feel it's time to re-invent vim, that it target a universal platform. There's really only one - the web. You can use it on every platform. Using the project node-webkit, there's really no reason not to use HTML5 and Javascript to develop an honestly modern application. (The sarcasm is dwindling, I'm half serious.)
I use vim myself, and generally stick to the basics of it because they allow me to edit very quickly. I don't really see the benefit of rewriting it, especially if you're going through so much trouble to retain compatibility with old plugins by compiling them to lua. Basically, you're setting yourselves up to run into the situation of having to re-implement vast portions of the PROBLEM you perceive with vim for that singular point.
Point: Just use vim.
The three things: Plugins, GUI, embedding
New plugin architecture retaining compatibility - already covered.
GUI - gvim's GUI has taught me just one thing over the years, that vim is not a GUI program. The GUI has the potential to make advanced functions more accessible, but re-implementing vim means you're starting without those functions in mind...
Embedding - this is one area where my interest is piqued. Embedding vim into other applications could be more elegant, but then embedding applications into other applications has always been a little odd, and this is one of those cases where you can run into some serious platform issues. This might actually be a case where that web technologies idea could bring incredible flexibility to the table.
Then there's always the option of using vim as an editor for the way it edits, and not getting caught up in the advanced functionality such as the GUI, and plugins, and embedding it as a plugin. Then we find a case where the entire effort is wasted, especially if it gets any of the details wrong in the basic functionality.
The system of rules and laws are really important to bring up in this context, and the reason for that is because of the protections that people enjoy due to the banking system. I've seen some arguments talking about how BitCoin is vulnerable to all kinds of things that fiat isn't, and the reasons they bring up are the banks and the banking system. But the problem with that in my eyes comes from the fact that the fiat currency doesn't have any of those protections whatsoever, they come only from the banking institution, and the banking institution will function similarly no matter what currency the banking system is shuffling around. I submit the global economy and all of the currencies involved in it as proof of concept.
I feel that you likely don't understand the process of development and the meaning of the version number.
The version number, "0.9.0", in this case represents a Pre-Release snapshot of the software code. You can tell because the first number, the Major version number, is 0. This usually means that the software is currently in development and is hopefully actively being worked on. In this case, we're being given information about a NEW release, which is versioned '0.9.0'. In other words, things are progressing in the manner they explicitly should and I take offense that you feel software grows on trees.
The vast, vast majority of personal computer units with integrated LAN cards happen to have network boot capability built in. It's been there since before they were an integrated component, even. Intel and Realtek make most of the ethernet chipsets I see around, and they both use a pretty bog standard PXE network booting stack. BIOS hackers would be acutely aware of it, I wouldn't be surprised if that's been exploited in some strikingly silly manner and used for this kind of thing.
Yeah, and even if it's 15GB, that leaves a vanishingly small amount of space on the hypothetical tablet. It's simply absurd that this is being presented as anything other than something to point and laugh at.
I have tried it myself, I actually decided to stick with Python 2 because I ran into plenty of awkward behavior and found that most of the third party modules I was interested in weren't available. Just now, as an example, I've visited this page (note the 3 in the URL). Trying to get up to date GUI library bindings for Python 3, I find the state of them to be quite disheartening. The PyGTK+ binding has been replaced by PyGObject in Python 3, but the PyGTK+ recommends staying with PyGTK+ on Windows. The rest aren't looking much better - our options are Tkinter and Qt if want to be '3 clean'. This exercise actually reminded me of something I discovered the last time I made the attempt to support Python 3 on Windows, the finding that I was explicitly limited to installing particular combinations of Python versions and libraries if I expected the libraries to actually work. Something was severely broken along the way, and I get the impression that it's one of those things that nobody will ever admit to.
With regard to the iOS devices, we have a really silly situation. We actually have a situation where the devices hadn't been properly handling SSL for YEARS, from the looks of it they even released an Out of Band update for iOS 6 because some perfectly capable handsets aren't compatible with iOS 7 and that would have caused Issues. The fact that it is even possible for such a thing to have happened is silly enough as is, but there ya go, this is what we get for so many falling into this closed ecosystem trap. It's a wall, and things are simply bound to crash into it. They should open their doors so we're not at their mercy for this level of CRITICAL SECURITY FLAW.
The way I've heard it the manner in which Python 3 has modified the Python Standard Library has made it so cases where you aren't working with pure Unicode data (such as in any real world problem) get all the hassle and more of Python 2. Interoperability with foreign systems is kind of a basic foundation of data processing, having to workaround inconsistencies with the Python 3 Standard Library to do so probably means it's no longer the right tool for the job.
Slashdot Mirror
This part kind of aggravates me, honestly. There's a chicken-and-egg problem when it comes to diddling with every relevant part of the stack and how they communicate with the driver layers. The most important part as far as maintaining compatibility and supporting existing systems is making it so that common (legacy is the wrong word) API layers continue to function utilizing the new back-ends, but the logistics of where that begins and ends are very much in flux with this development process. OpenGL is a natural, obvious solution with regard to 'language we use to draw to the display', but how OpenGL is implemented is very much in question with this process.
Hardware failure can't be avoided, but I think we can do better on the software side of things. I mean, if the Wayland project keeps going strong and the efforts to Not Break Everything keep progressing, we could end up with a case where X.org simply has a Wayland driver and while all the issues that can exist may exist, we can bypass a lot of the heartache if the project continues going smoothly. This article gives me hope that we're not destroying everything in this process.
I'll keep using my working computer.
This is entirely speculation until we've reached the point where the coins are no longer being issued.
After all of the bitcoins are mined, there is no longer an incentive to treat it in this goldrush-like manner. The only people who will have reason to run a miner are the people who use bitcoins as a currency, to be a node in their decentralized economy. Most of the problems people describe seem to be directly related to its use as a pump and dump, actually. I must wonder what's going to happen once we reach that point.
Fact is that I can remotely control almost any computer running on almost any platform utilizing countless different variations of the theme of 'render to the display - wait, let's render to an image instead then send it over the wire'
The reason so much attention is being put on display servers is as a distraction from the real problems, such as the fact that so much attention is being put on the display servers. They're not the weak point, there are a lot of them, and one exercise that remains THROUGHOUT COMPUTING HISTORY, is the task of updating software and porting it to another display server, because at the end of the day you're drawing colored rectangles on a screen.
The line between amateur and professional is one that is heavily drawn and maintained by a certain class of 'professionals'. It doesn't really matter what industry we're talking about on that one, what matters is the resources behind the individual worker. You create professionals by giving amateurs the resources they need to do their job efficiently and with high quality and by being able to provide them the wisdom (from honest professionals, not 'professional' professionals) they need to understand what mistakes they're making and how to solve them. A real journalist is defined by practicing journalism, and the content received from journalist-on-the-street is going to be more raw and real than the content coming from the professional. This might make the street journalist's word infinitely more valuable than the professional journalist's word, depending on whether the professional journalist is actually a journalist or just a professional.
It's gonna have the same problems either way. That's why it's so ridiculous and nobody can agree.
The points you mention are the reason why I advocate the use of tabs rather than spaces. I kinda feel like the guys who use spaces don't actually understand what they're doing when they indent, especially if they can't decide how many spaces an indent should be. Tab. One character. Indent.
I think he should automatically check for four spaces and replace them with a tab. That's a 75% reduction in whitespace size with the same meaning!
Intel has decent enough open source drivers, until you get to the chips like the GMA 500 that just don't quite DO that. Intel has done pretty good with Linux support overall, but they definitely haven't solved the problem.
I love the wide range of places that vi has ended up... I feel like we really need to go retrograde to have honest software innovation at this point, I like the idea of using a modern web browser to re-implement something like MobaXterm (it's a slick cyg/mingw terminal emulator package for Windows) and then using classical foundation technologies as the classical foundation on all these devices. The old unix philosophy of having the utilities do what they do well combined with the technology to put a shiny and solid interface on it.
But, even on my triple GHz quad-core workstation with 8 gigs of RAM, I can feel the drag of so many layers of abstraction when I'm playing with these web technologies that I suggested. Native application performance is truly unmatched and it doesn't have anything to do with how well put together these web applications are, the sandboxes just have too much baggage even with all the JIT tricks they're trying to pull these days.
Make your own damn Cosmos.
Geek card, please.
'Rebuilding Vim for the 21st Century' says it all. The problem with the 21st century from what I've seen, is this insistence that we must re-invent the ENTIRE wheel.
I'm going to suggest that if you feel it's time to re-invent vim, that it target a universal platform. There's really only one - the web. You can use it on every platform. Using the project node-webkit, there's really no reason not to use HTML5 and Javascript to develop an honestly modern application. (The sarcasm is dwindling, I'm half serious.)
I use vim myself, and generally stick to the basics of it because they allow me to edit very quickly. I don't really see the benefit of rewriting it, especially if you're going through so much trouble to retain compatibility with old plugins by compiling them to lua. Basically, you're setting yourselves up to run into the situation of having to re-implement vast portions of the PROBLEM you perceive with vim for that singular point.
Point: Just use vim.
The three things: Plugins, GUI, embedding
New plugin architecture retaining compatibility - already covered.
GUI - gvim's GUI has taught me just one thing over the years, that vim is not a GUI program. The GUI has the potential to make advanced functions more accessible, but re-implementing vim means you're starting without those functions in mind...
Embedding - this is one area where my interest is piqued. Embedding vim into other applications could be more elegant, but then embedding applications into other applications has always been a little odd, and this is one of those cases where you can run into some serious platform issues. This might actually be a case where that web technologies idea could bring incredible flexibility to the table.
Then there's always the option of using vim as an editor for the way it edits, and not getting caught up in the advanced functionality such as the GUI, and plugins, and embedding it as a plugin. Then we find a case where the entire effort is wasted, especially if it gets any of the details wrong in the basic functionality.
The system of rules and laws are really important to bring up in this context, and the reason for that is because of the protections that people enjoy due to the banking system. I've seen some arguments talking about how BitCoin is vulnerable to all kinds of things that fiat isn't, and the reasons they bring up are the banks and the banking system. But the problem with that in my eyes comes from the fact that the fiat currency doesn't have any of those protections whatsoever, they come only from the banking institution, and the banking institution will function similarly no matter what currency the banking system is shuffling around. I submit the global economy and all of the currencies involved in it as proof of concept.
I feel that you likely don't understand the process of development and the meaning of the version number.
The version number, "0.9.0", in this case represents a Pre-Release snapshot of the software code. You can tell because the first number, the Major version number, is 0. This usually means that the software is currently in development and is hopefully actively being worked on. In this case, we're being given information about a NEW release, which is versioned '0.9.0'. In other words, things are progressing in the manner they explicitly should and I take offense that you feel software grows on trees.
The arena shooter isn't dead, it just went free to play.
Most BIOSes + NICs have that little PXE booting stack hanging out in the option ROM. It's really not that farfetched by any means.
The vast, vast majority of personal computer units with integrated LAN cards happen to have network boot capability built in. It's been there since before they were an integrated component, even. Intel and Realtek make most of the ethernet chipsets I see around, and they both use a pretty bog standard PXE network booting stack. BIOS hackers would be acutely aware of it, I wouldn't be surprised if that's been exploited in some strikingly silly manner and used for this kind of thing.
Yeah, and even if it's 15GB, that leaves a vanishingly small amount of space on the hypothetical tablet. It's simply absurd that this is being presented as anything other than something to point and laugh at.
I have tried it myself, I actually decided to stick with Python 2 because I ran into plenty of awkward behavior and found that most of the third party modules I was interested in weren't available. Just now, as an example, I've visited this page (note the 3 in the URL). Trying to get up to date GUI library bindings for Python 3, I find the state of them to be quite disheartening. The PyGTK+ binding has been replaced by PyGObject in Python 3, but the PyGTK+ recommends staying with PyGTK+ on Windows. The rest aren't looking much better - our options are Tkinter and Qt if want to be '3 clean'. This exercise actually reminded me of something I discovered the last time I made the attempt to support Python 3 on Windows, the finding that I was explicitly limited to installing particular combinations of Python versions and libraries if I expected the libraries to actually work. Something was severely broken along the way, and I get the impression that it's one of those things that nobody will ever admit to.
With regard to the iOS devices, we have a really silly situation. We actually have a situation where the devices hadn't been properly handling SSL for YEARS, from the looks of it they even released an Out of Band update for iOS 6 because some perfectly capable handsets aren't compatible with iOS 7 and that would have caused Issues. The fact that it is even possible for such a thing to have happened is silly enough as is, but there ya go, this is what we get for so many falling into this closed ecosystem trap. It's a wall, and things are simply bound to crash into it. They should open their doors so we're not at their mercy for this level of CRITICAL SECURITY FLAW.
The way I've heard it the manner in which Python 3 has modified the Python Standard Library has made it so cases where you aren't working with pure Unicode data (such as in any real world problem) get all the hassle and more of Python 2. Interoperability with foreign systems is kind of a basic foundation of data processing, having to workaround inconsistencies with the Python 3 Standard Library to do so probably means it's no longer the right tool for the job.
Somehow I think the problem may be on your end, bro.