Yeah, but KDE is not Linux, and Linux doesn't know where that driving philosophy hides. Linux is KDE/GNOME/Whatever
it's a good thing, that proprietory vendors have a cost increase with every additional distro supported while free software developers get pretty much all distros for free
Please explain how proprietary vendors have to abide by different rules than open source developers please. Also, your statement is quite obviously false since the vast majority of software vendors are entirely un-interested in developing for Linux.
The latter part of your infantile rant is also proven wrong by the fact that statistically ZERO vendors develop for Linux. I have zero problems developing for, on and under Linux, and I have been doing so for years. In fact, I was part of a team that delivered one of the first commercial applications written in Java, running mainly on Linux (and SunOS and HP-UX) way back in the late 1990s. The fact that there are no (statistically) commercial apps for Linux shows two things, one of them mirrored on Android: 1/ Developing good UI apps for the Linux platform is hard, and it is difficult to chose a technology that will be consistent and functional over time. 2/ Linux users don't buy desktop apps (Android users are far more reluctant than iOS users to pay for apps).
Consider someone like Adobe, they have a vast array of industry-leading apps, they are functionally identical on Windows and on OSX. You can be quite sure that Adobe has a clear separation between application logic and display logic, otherwise the apps would end up having far more issues that were platform specific than they do. This means that the majority of something like After Effects is already mostly platform independent. Porting from OSX to Linux would be anything but trivial, but a reasonably cost-efficient project. If there was a customer base. However, they would have to chose between (for example) KDE and GNOME. The problem is that one year KDE is the hottest thing in Linux land the next GNOME is. Who knows which is next. This drives up maintenance cost for a platform where nobody buys software. Business wise it would be idiotic for Adobe to go that route with anything marginally more complex than what they have on mobile.
If anybody in Linux land ever cared about the desktop, there would be a single UI platform with a consistent and long-lived API. Nobody cares about that though. This is why Linux is a (great) server OS, a mediocre desktop OS, and will never conquer the mainstream desktop platform. Ever. OSX won the Unix on the desktop war, and if you need a decent Unix on the desktop for running something that is not developer tools, you'd be insane to chose anything BUT OSX.
End words: I have been using Linux to develop cross-platform apps since some time in the 1990s. After moving into the mobile space I was "forced" to get a Mac since mobile today == iOS (Android users don't pay for apps) and you are basically required to have a Mac for iOS development (has recently changed a little, but that's another matter). OSX is what Linux could have been 10 years ago if someone had ever cared. Nobody ever did, and today there is only one rational solution for Unix on the Desktop.
Should have added: Re-factoring is also fantastic. It's a lot easier to do re-factoring when the re-factoring engine compiles and links the code to ensure accurate results.
is this related to projects that use C++, Net and other forms of object oriented programming languages where you have tons of classes, members and files?
Yes.
Or for visual type of programming where you design GUI:s by drag and drop?
If I say that I have never done that, it would be a tiny bit of a lie, I once used Delphi working like that. I only do server-side and web stuff, and for that Visual Studio is amazing. It's of course best for C# since the entire C# compiler system is built into the text editor (it compiles the code as you write it, making things like intellisense exceedingly accurate and lightning fast. Though it is not as configurable as, for example, Eclipse, it is more than configurable enough, and for speed it blows Eclipse out of the water. IntelliJ a little less so, but still, it's not even close. I would not (obviously) use VS for Java, but for C++, C# and cross-platform mobile development (for example) it can't be beat.
Yeah because just that I believe that most IT stuff can be done faster using a CLI than with a GUI
A tiny tip to clue you in. Just a little bit. 99.999% of the worlds population never uses their computer for "most IT stuff". Do you know what the word "mainstream" means? I use Unix variations for development, and grep. awk and all of that is great. It's not "mainstream" though. Not by a mile.
closer to moronic is pretending that it is not possible without even knowing
I do photography. I do software development. I use ImageMagick in a few places to alter photographs. Photo editing is not and never was, something you can do with ImageMagick. Photo editing is not making global changes to images or crop a bunch of them in the same way. Photo editing is what you do in tools like Lightroom, Photoshop (or Elements) and GiMP. It is not something you do in ImageMagick. "without even knowing". I know that ImageMagick is not photo editing software. Attempting to present it as such is moronic by definition. It's like me suggesting Neil Armstrong should have taken his bicycle to go to the moon in 1969. Moronic. By definition. So, no, it's not my opinion he's a moron, he is by definition.
calling me a liar because I have used it to do batch processing of images on many occasions
ImageMagick is very good for this. It's not photo editing though.
The biggest thing I hope to see change is Apple start publishing iTunes for Linux
Are you serious? iTunes is a horrible piece of shit software. On my Mac. On my Windows 10 box. I wouldn't want it polluting my Linux development environment too.
No. It doesn't even come close to working for what users do. Try not to be a moron. Remember, it's better to sit quietly in the corner having everybody think you're a retard than to post in public and remove any lingering doubt.
A good terminal (like bash) lets you do stuff faster and easier than any GUI.
Cool, I just shot 10 images in succession while panning. Can you please stitch them together to make a panorama? Did I mention they were RAW images? You need to read the raw, stitch them, add 10% contrast, take exposure down about.75 of a stop, add some micro contrast, adjust some curves, export in aRGB for printing and sRGB for the web. When you're done, I've got the 4K video I'd like you to edit. It consists of 25 clips, you need to...
Here is a clue for you: The average person can do basically none of the work they regularly do on a computer from the command line, and if you could cobble together stuff to do some of the above, it would be insanely difficult compared to firing up Lightroom or Capture one.
the project files for Visual Studio is a complete nightmare
And now they are no longer even XML, but JSON. That'll change every single release too:-) - the joy of the "could not migrate project" messages. Still, Visual Studio blows every other IDE or development environment out of the water. Particularly the nightmarish shit put out by Apple.
it's easier to tell someone how to do something from a command line than to direct them to do something via the gui.
Reply to This
Really? Wow! Great! Now, can you please tell me how to do this. I have a Sony A7R2 camera and I shoot raw. I would like to open the file, reduce exposure by 1.3 stops, adjust the R and G curves slightly, add some sharpening, set a white point, set a black point, lift the shadows a little, take down the highlights and publish it in aRGB for printing and sRGB for the web. Using the command line if you please.
For the vast (like 99.9%) amount of the work people do on their computers, the command line is utterly useless. Sure, when I set up a new Node project is is great, but then again, 99.9% of computer users don't know what Node is.
Yeah, this is true, but there is a reason for it. A large multi-user system running on slow disks will (statistically) benefit from a somewhat fragmented file system. Do the maths. Of course, this hurts WNT on the desktop. The general idea is that one user task will nor process an entire file in the time-slice alotted for it to run, so when it is pre-empted, the next task will need to read a different file somewhere else on the disk, in other words, moving the read head, and before it is finished with its file it will be pre.empted, the read head will be moved again, to another place on the disk, etc. In such a scenario a fragmented file system will have higher performance than a non-fragmented system due to the read head moving shorter (on average) distances each time.
Imagine two files on a one-platter spindle. One file is on the "inner" side of the spindle, the other on the "outer". Two processes are reading one file each, but are being pre-empted multiple times during the reads. For each task switch, the read head will have to move from the outer to the inner part of the spindle, or inner to outer. In other words, for each time slice, the read head moves across the entire disk. If the files are fragmented and the fragments are spread across the disk randomly, the disk head will, on average, only move across half the spindle each time. So, at the time of design and implementation, based on the purpose of the OS (both big server and desktop were imagined) an intentionally fragmented file system made sense. The problem is that one have to live with decisions like that for a long time:-)
A fundamentally broken and insecure security model
Again, in the OS, no the model is not broken, but the way Microsoft configured it, it did become broken. Mostly because of the elevated privileges needed for the first few years to do just about anything. But still, not a bad feature of the OS. In fact, again in the OS implementation, it beats the woefully simplistic and inadequate Unix security model of the time (and for many, still at this point in time).
When I develop for Android (I do) I develop for one environment using one set of APIs, where my application will be deployed on a consistent, coherent and fully sane user environment. None of that is true for desktop Linux. The fact that Linux is not having a showing on the desktop has nothing to do with Microsoft and everything to do with Linux/GNOME/KDE/X/(all kinds of other shit).
For the average user, choice is bad, options are bad, configurability is bad. Users don't want options and choice, they want consistency. Microsoft and Apple, even through the Win8-10 debacle, gives them that The fact that nobody in the Linux community have been able to put together a coherent user experience is the ONLY reason Linux has failed, and will continue to fail, on the desktop. Luckily for most, the desktop is becoming less and less relevant.
because when they bought their computers, Windows was already installed
Nonsense. The reason people don't use it is because it is a mess, and the desktop environment(s) were never a priority. If Linux had a single desktop environment that everybody used, and everybody developed to, it would be far more successful on the desktop. As it is now, you'd be almost completely insane to develop mainstream software for Linux.
The only successful Linux for end-users is Android, and Android (mostly) fixes this problem.
Simply put, for the end-user, Linux on the desktop is still garbage with no real software.
First Apple does have skylake processors in it's line up
Not in the models this article is about. You should read more than the headline. The Pro models are not being updated. Apple is also very late with updates to FCPX. Apple has long hinted it doesn't give a shit about the professional market, and this is more evidence. The old bread and butter market for Apple, graphical designers, video professionals etc are dropping Apple. Not strange. Their Pro line of products have been a joke for at least two years.
You're going to argue that Play in 2009 was not obscure? Your audacity is mind-boggling.
It was the most light-weight, most non-obscure of all the Java frameworks. I understand this can be difficult to understand. Ask someone who knows Java the next time you meet them. Now, can you find another source that agrees with your moronic 10:1 advantage? Fanbois are tiring.
So linq is generally useless according to your own statements for the class of systems we're discussing
Did I ever argue it was? However, in all systems there are significant portions that are not performance critical. Even if the overall system is. In those areas, Linq is better than the alternatives.
not least of which was obscurity
Obscurity? You have to be kidding me.
The only statement I'm making is that your statement implying that Play ported anything from.NET is a complete fallacy
So you clearly know a lot more than the creators of the Play framework. You can go here and see what the Play framework creators think that they them selves did, but hey, you probably know best. Play comes with Twirl, a powerful Scala-based template engine, whose design was inspired by ASP.NET Razor. Does it hurt to be that dumb?
you were processing a multi-million row complex data set on the fly for every query?
Talking about reading comprehension...Imagine processing a certain type of performance data every 15 minutes. This is the monstrous data set. As part of that processing, you are required to enrich certain records with data retrieved at the beginning of the fifteen minute interval from an external source. One where you have no ability to control the result set size. Was that difficult to comprehend? That data must be processed, in memory, prior to you being able to do any form of data enrichment. Was that difficult to comprehend? Again, have you ever worked with external data providers?
Setting up a simple searchable data polling proxy service, however, should take you all of a couple of weeks, tops
You have clearly never worked with the government. It can't do anything in "a couple of weeks". A couple of years, perhaps. The big telcos are similar, or at least were ten years ago.
NPM
Sigh.
Hey, let's see you back up your 10:1 speed difference. Moron.
That's why I restrict linq discussions purely to DBs
No, that's not why you restricted it to just DBs. You restricted it to DBs because you are ignorant. You don't use Linq2SQL in your app. It's that fucking simple. Not if performance is important. If performance is not important you also do not use Linq2SQL, you use the Entity Framework, which can be queried by using Linq, but it isn't a part of the framework. Linq is not, has never been, and will never be a DB framework. You are equating your own ignorant opinion to basic facts. The problem with opinions is that they are lie assholes. Everybody has one and they mostly stink. Fact: Linq has nothing to do with DB access. Your opinion in that matter is irrelevant. It is contradicted by fact. Also, more on your vast inexperience below when you say retarded stuff like: "You're already toast in my scenarios if you are passing more data than you need into your applications and are parsing shit in memory"
But some languages and features promote bad architecture
Java and C# are basically identical. The framework that have grown up around them are also basically identical (and porting between the two is plentiful, so you can get monstrosities like nHibernate and more useful stuff like log4net. Yes, languages and frameworks promote bad architecture, and Java and C# are so close to being identical that they promote identical architectural solutions. Since C# has developed in the wake of Java, it has avoided some of the monstrosities of Java, such as EJBs and the whole J2EE nonsense. Conversely, where interesting stuff was done in.Net, Java developers picked it up. The Play Framework v1 is basically what you would get if you port the good parts of -NET MVC to Java. V 2.0 is what you get if you employ the same job on Play 1 using Scala as your language.
yet you failed to comprehend what that example was telling you
No, it told me plenty. All of it about you. You have no experience with larger systems. You have no experience integrating with external systems over which you have no control. Here is an example of your mind-boggling in-experience. Your comment "You're already toast in my scenarios if you are passing more data than you need into your applications and are parsing shit in memory". I even told you why this was necessary but you simply have no experience with integrating with external systems. You therefore have never been in a situation where you have no choice. The service I was specifically talking about above was an external government (non-US) service which we could query for information vital to our system. The service had no search facilities, it had no possibility of limiting the data set you pulled down. In other words, we had no choice but pulling the data down, and it had to be real-time and do the filtering in memory. It took us seven years to get them to put an API in place and it would have taken us another five to get them to make the data searchable. You have clearly never attempted to gather data from data sources that were not your own and that you therefore had no control over whatsoever.
As for Apple 1) they built it on AWS, 2) when Azure was stable enough they distributed their risk. 3) Azure is at least 33% Linux based
Apple built the iCloud on AWS and Azure simultaneously, and the two serve somewhat different purposes. But hey, let's look at the rest of your statemment, shall we?
3) Azure is at least 33% Linux based
Yes, obviously. Microsoft released Linux on Azure in 2013, after it having been available in Beta since late 2012. So, when did Apple launch the iCloud on Azure? 2011.
You are a pretentious fool
If I was pretentious I would have to make positive statements about something. The only example of self I have used was in response to some pretentious nonsense you blabbered about on
it pretty much fails to deliver as soon as you get to anything interesting
Could you elaborate please? Again, keep databases out of it, Linq is not a database framework. The fact that you continue to compare Linq to Hibernate shows you think Linq is database related, which just shows your ignorance. Linq has nothing to do with databases.
Lambdas? I haven't seen where they are significantly better than other simpler solutions
You are kidding right? Lambdas are the simple solution, they make code more succinct and to the point than the alternatives. Your statement shows that you think you know best and everybody else is wrong. This just shows a staggering level of ignorance. There is a reason "everybody" wants Lambdas. They make your code better. They are not magical, but succinct code is better than overly verbose code, which the code is when not using lambdas.
You can accept that statement as is or not.
Considering the fact that all you have provided so far is ignorant nonsense (about both lambdas and Linq) I take what you say for what it is. The ramblings of someone who's relevance has come (being nice here) and gone. Probably decades ago.
The Java app was far more modular
So you are not comparing Java to C#/.Net. They two are close to identical in base features, so it is impossible to make a Java app that is more modular than you can make a.Net app. What you are saying above is that you are comparing the code of a bunch of morons who could not make a modular app to the code of competent developers that could. That's the comparison of an ignorant moron. There is nothing in Java that makes it possible to create more modular apps than you could in.Net. Quite the opposite in fact, at the moment, since DI etc is a core part of the.Net framework, it is easier to create modular.Net apps than Java apps out of the box. In Java you first have to figure out, for example, what DI framework to use.
Sometimes bad architecture lays a crumbling foundation that just can't be corrected.
Yeah, but bad architecture is not a framework or language feature. Bad architecture is a feature of the software developers implementing the solution. Using bad developers as an example to illustrate bad frameworks or bad languages is moronic, to put it mildly. If you had any experience as a developer, you would know that.
Java's outperforming C# is based on real world scenarios
No, it is not, and you just said it is not. In real world scenarios nobody in the world has observed what you claim. You are the only one. So, is everybody in the world an idiot and you a genius? Probably not, you are just ignorant. You said that the reason the systems you were struggling with were bad was because of incompetent developers, not a bad framework or a bad language decision. The performance is based on the fact that the developers you are talking about were morons, not that the tools they had selected were bad. Bad architecture creates un-maintainable software, bad architecture will usually result in under-performing software, but that has nothing to do with the tools. Seriously. You can't be this dumb!
A current startup project is still in testing stages, and tables are already touching 1M rows...
If each of those calls hit 5 tables...
So you are talking about relatively small systems with few tables and quite moderate amounts of data. OK. That may explain things. You simply haven't worked on teams where performance is an issue, you have had some straight-out-of-school kids do some stuff in.Net, and you think that you have worked on big data stuff. That's more than just a little sad.
Imagine an MPLS switched network with about 20 000 nodes, switches some servers
I assume, since this was in a DB context, you meant Linq, Lync is a messenger thingimajig I believe. Linq is a language feature not a tool, if you don't know what tools are ask a programmer. Oh, and I doubt the number of developers in the.Net world that uses Linq2SQL directly is insignificant, if you are dealing with a DB you're probably using the.Net equivalent to Hibernate, the Entity Framework. The developers of the Entity Framework did learn a thing or two from Hibernate though, and the Entity Framework, though far from perfect, is far less of a clusterfuck than Hibernate is. Still, neither are great for DB apps with significant performance requirements. Entity Framework blows Hibernate out of the water though. Both in performance and usability. Nuclear blast style blows out of the water. Where EF is just not great, Hibernate should actually be banned from the Enterprise, and in many companies where I have worked, it actually is.
Linq on the other hand just another way to write Lambda expressions, in fact, Linq queries are compiled to Lambda expressions by the C# compiler. If Linq is bad then Lambdas are bad. If Lambdas are bad then I am curious as to why the Java community has been begging for them for years. Linq can be used to write lambdas for any collection type. I currently fetch Json from a very, very slow government server somewhere and I use lambdas to parse the data as it comes back. Since the server in question doesn't do any filtering on the data at all, and I'm only interested in about 5% of what it returns, having a single line of code extracting what I need is cool. I can write [obviously it's a tad more complex] var myStuff = allStuff.Where( s => "value".Equals(s.property)); which is quite useful. The code runs once every 24 hours, so I don't really care if it runs in 2ms or 3ms. If performance was critical, I might have written it differently. Why being able to query Json like that would be a bad thing is a mystery to me. Can you elaborate please? Why are lambdas horrible? I could have written it in Linq too (from d in data where d.property == "value" select d) but that would have been more verbose and to me (but that is just preference) less clear. The code is identical though, once it's run through the first compiler step. As a side note - about a year ago that server returned a highly convoluted XML stream instead of Json. The code to filter my data from the XML result didn't change at all. I can query Json, XML, a list of C# objects or a database with the same line of code. As I said, I'm not saying it is hugely performant, but for most Enterprise applications that is actually not an issue.
Now, you can easily argue that Lambdas (and by association Linq) are not performant enough for high-performance applications, and depending on how the lambda implementation for various entities, you would most of the time be correct. So, stay away from them. Linq and Lambdas are great for many types of applications where performance is perhaps important but load is lower.
The Java system easily outperformed the.NET system by a factor of 10:1
Seriously? This comment alone shows that you are lying through your teeth. There isn't a single benchmark in the world that would give a ten to one speed advantage for Java over.Net. Not one. It's pure balderdash.
was updated multiple times for each.NET update cycle
So you claim it is easier to update Java apps than C# apps? That's just nonsense. Fanboi warning. Remember, your programming language is a tool, not a savior of your soul. Get a grip. The similarities between C# and Java are significantly more important than the differences, but C# tooling is far better. Re-factoring, for example, in Visual Studio with Re-Sharper blows the Eclipse variation out of the water, it easily beats IntelliJ too. The fact
Can you elaborate on why?:Net and C# beats the Java platform in every single way except perhaps one, the Play Framework, which originally was basically.Net MVC ported to Java.
Would be better to use an open source toolkit rather than to make oneself hostage of MS,
Ah, that explains it. You are just clueless. Let''s see, what Open Source tools are.Net comprised of? Well, all of.Net obviously. The C# Compiler too. Is the Java compiler open source? More? Yeah, Visual Studio is free, but it isn't open source, but then again, Visual Studio Code, a very good IDE for just about anything is. Yeah, so ALL the tools I use on my MacBook Pro to develop Angular and Ionic apps with.Net back-ends are in fact open source. Wow. You get the price for the most clueless person still living in the 1990s.
Slashdot Mirror
personal definition
Yes, the way every single person in the entire world (statistically) does it is my "personal definition".
that's been KDE's driving philosophy for years
Yeah, but KDE is not Linux, and Linux doesn't know where that driving philosophy hides. Linux is KDE/GNOME/Whatever
it's a good thing, that proprietory vendors have a cost increase with every additional distro supported while free software developers get pretty much all distros for free
Please explain how proprietary vendors have to abide by different rules than open source developers please. Also, your statement is quite obviously false since the vast majority of software vendors are entirely un-interested in developing for Linux.
The latter part of your infantile rant is also proven wrong by the fact that statistically ZERO vendors develop for Linux. I have zero problems developing for, on and under Linux, and I have been doing so for years. In fact, I was part of a team that delivered one of the first commercial applications written in Java, running mainly on Linux (and SunOS and HP-UX) way back in the late 1990s. The fact that there are no (statistically) commercial apps for Linux shows two things, one of them mirrored on Android: 1/ Developing good UI apps for the Linux platform is hard, and it is difficult to chose a technology that will be consistent and functional over time. 2/ Linux users don't buy desktop apps (Android users are far more reluctant than iOS users to pay for apps).
Consider someone like Adobe, they have a vast array of industry-leading apps, they are functionally identical on Windows and on OSX. You can be quite sure that Adobe has a clear separation between application logic and display logic, otherwise the apps would end up having far more issues that were platform specific than they do. This means that the majority of something like After Effects is already mostly platform independent. Porting from OSX to Linux would be anything but trivial, but a reasonably cost-efficient project. If there was a customer base. However, they would have to chose between (for example) KDE and GNOME. The problem is that one year KDE is the hottest thing in Linux land the next GNOME is. Who knows which is next. This drives up maintenance cost for a platform where nobody buys software. Business wise it would be idiotic for Adobe to go that route with anything marginally more complex than what they have on mobile.
If anybody in Linux land ever cared about the desktop, there would be a single UI platform with a consistent and long-lived API. Nobody cares about that though. This is why Linux is a (great) server OS, a mediocre desktop OS, and will never conquer the mainstream desktop platform. Ever. OSX won the Unix on the desktop war, and if you need a decent Unix on the desktop for running something that is not developer tools, you'd be insane to chose anything BUT OSX.
End words: I have been using Linux to develop cross-platform apps since some time in the 1990s. After moving into the mobile space I was "forced" to get a Mac since mobile today == iOS (Android users don't pay for apps) and you are basically required to have a Mac for iOS development (has recently changed a little, but that's another matter). OSX is what Linux could have been 10 years ago if someone had ever cared. Nobody ever did, and today there is only one rational solution for Unix on the Desktop.
Should have added: Re-factoring is also fantastic. It's a lot easier to do re-factoring when the re-factoring engine compiles and links the code to ensure accurate results.
is this related to projects that use C++, Net and other forms of object oriented programming languages where you have tons of classes, members and files?
Yes.
Or for visual type of programming where you design GUI:s by drag and drop?
If I say that I have never done that, it would be a tiny bit of a lie, I once used Delphi working like that. I only do server-side and web stuff, and for that Visual Studio is amazing. It's of course best for C# since the entire C# compiler system is built into the text editor (it compiles the code as you write it, making things like intellisense exceedingly accurate and lightning fast. Though it is not as configurable as, for example, Eclipse, it is more than configurable enough, and for speed it blows Eclipse out of the water. IntelliJ a little less so, but still, it's not even close. I would not (obviously) use VS for Java, but for C++, C# and cross-platform mobile development (for example) it can't be beat.
Yeah because just that I believe that most IT stuff can be done faster using a CLI than with a GUI
A tiny tip to clue you in. Just a little bit. 99.999% of the worlds population never uses their computer for "most IT stuff". Do you know what the word "mainstream" means? I use Unix variations for development, and grep. awk and all of that is great. It's not "mainstream" though. Not by a mile.
closer to moronic is pretending that it is not possible without even knowing
I do photography. I do software development. I use ImageMagick in a few places to alter photographs. Photo editing is not and never was, something you can do with ImageMagick. Photo editing is not making global changes to images or crop a bunch of them in the same way. Photo editing is what you do in tools like Lightroom, Photoshop (or Elements) and GiMP. It is not something you do in ImageMagick. "without even knowing". I know that ImageMagick is not photo editing software. Attempting to present it as such is moronic by definition. It's like me suggesting Neil Armstrong should have taken his bicycle to go to the moon in 1969. Moronic. By definition. So, no, it's not my opinion he's a moron, he is by definition.
calling me a liar because I have used it to do batch processing of images on many occasions
ImageMagick is very good for this. It's not photo editing though.
Someone who claims that you can use ImageMagick for photo editing is a moron, that's just reality, not my opinion. Stating a fact is not insulting.
The biggest thing I hope to see change is Apple start publishing iTunes for Linux
Are you serious? iTunes is a horrible piece of shit software. On my Mac. On my Windows 10 box. I wouldn't want it polluting my Linux development environment too.
Yes - (www.imagemagick.org)
No. It doesn't even come close to working for what users do. Try not to be a moron. Remember, it's better to sit quietly in the corner having everybody think you're a retard than to post in public and remove any lingering doubt.
A good terminal (like bash) lets you do stuff faster and easier than any GUI.
Cool, I just shot 10 images in succession while panning. Can you please stitch them together to make a panorama? Did I mention they were RAW images? You need to read the raw, stitch them, add 10% contrast, take exposure down about .75 of a stop, add some micro contrast, adjust some curves, export in aRGB for printing and sRGB for the web. When you're done, I've got the 4K video I'd like you to edit. It consists of 25 clips, you need to...
Here is a clue for you: The average person can do basically none of the work they regularly do on a computer from the command line, and if you could cobble together stuff to do some of the above, it would be insanely difficult compared to firing up Lightroom or Capture one.
the project files for Visual Studio is a complete nightmare
And now they are no longer even XML, but JSON. That'll change every single release too :-) - the joy of the "could not migrate project" messages. Still, Visual Studio blows every other IDE or development environment out of the water. Particularly the nightmarish shit put out by Apple.
it's easier to tell someone how to do something from a command line than to direct them to do something via the gui. Reply to This
Really? Wow! Great! Now, can you please tell me how to do this. I have a Sony A7R2 camera and I shoot raw. I would like to open the file, reduce exposure by 1.3 stops, adjust the R and G curves slightly, add some sharpening, set a white point, set a black point, lift the shadows a little, take down the highlights and publish it in aRGB for printing and sRGB for the web. Using the command line if you please.
For the vast (like 99.9%) amount of the work people do on their computers, the command line is utterly useless. Sure, when I set up a new Node project is is great, but then again, 99.9% of computer users don't know what Node is.
Well, there are a few errors here, but..
The Registry
Not really part of the OS
NTFS - designed to fragment
Yeah, this is true, but there is a reason for it. A large multi-user system running on slow disks will (statistically) benefit from a somewhat fragmented file system. Do the maths. Of course, this hurts WNT on the desktop. The general idea is that one user task will nor process an entire file in the time-slice alotted for it to run, so when it is pre-empted, the next task will need to read a different file somewhere else on the disk, in other words, moving the read head, and before it is finished with its file it will be pre.empted, the read head will be moved again, to another place on the disk, etc. In such a scenario a fragmented file system will have higher performance than a non-fragmented system due to the read head moving shorter (on average) distances each time.
Imagine two files on a one-platter spindle. One file is on the "inner" side of the spindle, the other on the "outer". Two processes are reading one file each, but are being pre-empted multiple times during the reads. For each task switch, the read head will have to move from the outer to the inner part of the spindle, or inner to outer. In other words, for each time slice, the read head moves across the entire disk. If the files are fragmented and the fragments are spread across the disk randomly, the disk head will, on average, only move across half the spindle each time. So, at the time of design and implementation, based on the purpose of the OS (both big server and desktop were imagined) an intentionally fragmented file system made sense. The problem is that one have to live with decisions like that for a long time :-)
A fundamentally broken and insecure security model
Again, in the OS, no the model is not broken, but the way Microsoft configured it, it did become broken. Mostly because of the elevated privileges needed for the first few years to do just about anything. But still, not a bad feature of the OS. In fact, again in the OS implementation, it beats the woefully simplistic and inadequate Unix security model of the time (and for many, still at this point in time).
Android (has a Linux kernel) has 86.2%
When I develop for Android (I do) I develop for one environment using one set of APIs, where my application will be deployed on a consistent, coherent and fully sane user environment. None of that is true for desktop Linux. The fact that Linux is not having a showing on the desktop has nothing to do with Microsoft and everything to do with Linux/GNOME/KDE/X/(all kinds of other shit).
For the average user, choice is bad, options are bad, configurability is bad. Users don't want options and choice, they want consistency. Microsoft and Apple, even through the Win8-10 debacle, gives them that The fact that nobody in the Linux community have been able to put together a coherent user experience is the ONLY reason Linux has failed, and will continue to fail, on the desktop. Luckily for most, the desktop is becoming less and less relevant.
because when they bought their computers, Windows was already installed
Nonsense. The reason people don't use it is because it is a mess, and the desktop environment(s) were never a priority. If Linux had a single desktop environment that everybody used, and everybody developed to, it would be far more successful on the desktop. As it is now, you'd be almost completely insane to develop mainstream software for Linux.
The only successful Linux for end-users is Android, and Android (mostly) fixes this problem.
Simply put, for the end-user, Linux on the desktop is still garbage with no real software.
Linux is 50 year old technology wrapped in a (hugely bloated) 25 year old package. Time for something better (no, not from Microsoft or Apple).
First Apple does have skylake processors in it's line up
Not in the models this article is about. You should read more than the headline. The Pro models are not being updated. Apple is also very late with updates to FCPX. Apple has long hinted it doesn't give a shit about the professional market, and this is more evidence. The old bread and butter market for Apple, graphical designers, video professionals etc are dropping Apple. Not strange. Their Pro line of products have been a joke for at least two years.
something about 4 CPU systems being the max at the time
Ignorant BS. You just proved your self 100% clueless.
You're going to argue that Play in 2009 was not obscure? Your audacity is mind-boggling.
It was the most light-weight, most non-obscure of all the Java frameworks. I understand this can be difficult to understand. Ask someone who knows Java the next time you meet them. Now, can you find another source that agrees with your moronic 10:1 advantage? Fanbois are tiring.
So linq is generally useless according to your own statements for the class of systems we're discussing
Did I ever argue it was? However, in all systems there are significant portions that are not performance critical. Even if the overall system is. In those areas, Linq is better than the alternatives.
not least of which was obscurity
Obscurity? You have to be kidding me.
The only statement I'm making is that your statement implying that Play ported anything from .NET is a complete fallacy
So you clearly know a lot more than the creators of the Play framework. You can go here and see what the Play framework creators think that they them selves did, but hey, you probably know best. Play comes with Twirl, a powerful Scala-based template engine, whose design was inspired by ASP.NET Razor. Does it hurt to be that dumb?
you were processing a multi-million row complex data set on the fly for every query?
Talking about reading comprehension...Imagine processing a certain type of performance data every 15 minutes. This is the monstrous data set. As part of that processing, you are required to enrich certain records with data retrieved at the beginning of the fifteen minute interval from an external source. One where you have no ability to control the result set size. Was that difficult to comprehend? That data must be processed, in memory, prior to you being able to do any form of data enrichment. Was that difficult to comprehend? Again, have you ever worked with external data providers?
Setting up a simple searchable data polling proxy service, however, should take you all of a couple of weeks, tops
You have clearly never worked with the government. It can't do anything in "a couple of weeks". A couple of years, perhaps. The big telcos are similar, or at least were ten years ago.
NPM
Sigh.
Hey, let's see you back up your 10:1 speed difference. Moron.
Now? When were they not able to? Not strange though, there is no better Unix desktop OS than OSX (now macOS) so...
That's why I restrict linq discussions purely to DBs
No, that's not why you restricted it to just DBs. You restricted it to DBs because you are ignorant. You don't use Linq2SQL in your app. It's that fucking simple. Not if performance is important. If performance is not important you also do not use Linq2SQL, you use the Entity Framework, which can be queried by using Linq, but it isn't a part of the framework. Linq is not, has never been, and will never be a DB framework. You are equating your own ignorant opinion to basic facts. The problem with opinions is that they are lie assholes. Everybody has one and they mostly stink. Fact: Linq has nothing to do with DB access. Your opinion in that matter is irrelevant. It is contradicted by fact. Also, more on your vast inexperience below when you say retarded stuff like: "You're already toast in my scenarios if you are passing more data than you need into your applications and are parsing shit in memory"
But some languages and features promote bad architecture
Java and C# are basically identical. The framework that have grown up around them are also basically identical (and porting between the two is plentiful, so you can get monstrosities like nHibernate and more useful stuff like log4net. Yes, languages and frameworks promote bad architecture, and Java and C# are so close to being identical that they promote identical architectural solutions. Since C# has developed in the wake of Java, it has avoided some of the monstrosities of Java, such as EJBs and the whole J2EE nonsense. Conversely, where interesting stuff was done in .Net, Java developers picked it up. The Play Framework v1 is basically what you would get if you port the good parts of -NET MVC to Java. V 2.0 is what you get if you employ the same job on Play 1 using Scala as your language.
yet you failed to comprehend what that example was telling you
No, it told me plenty. All of it about you. You have no experience with larger systems. You have no experience integrating with external systems over which you have no control. Here is an example of your mind-boggling in-experience. Your comment "You're already toast in my scenarios if you are passing more data than you need into your applications and are parsing shit in memory". I even told you why this was necessary but you simply have no experience with integrating with external systems. You therefore have never been in a situation where you have no choice. The service I was specifically talking about above was an external government (non-US) service which we could query for information vital to our system. The service had no search facilities, it had no possibility of limiting the data set you pulled down. In other words, we had no choice but pulling the data down, and it had to be real-time and do the filtering in memory. It took us seven years to get them to put an API in place and it would have taken us another five to get them to make the data searchable. You have clearly never attempted to gather data from data sources that were not your own and that you therefore had no control over whatsoever.
As for Apple 1) they built it on AWS, 2) when Azure was stable enough they distributed their risk. 3) Azure is at least 33% Linux based
Apple built the iCloud on AWS and Azure simultaneously, and the two serve somewhat different purposes. But hey, let's look at the rest of your statemment, shall we?
3) Azure is at least 33% Linux based
Yes, obviously. Microsoft released Linux on Azure in 2013, after it having been available in Beta since late 2012. So, when did Apple launch the iCloud on Azure? 2011.
You are a pretentious fool
If I was pretentious I would have to make positive statements about something. The only example of self I have used was in response to some pretentious nonsense you blabbered about on
it pretty much fails to deliver as soon as you get to anything interesting
Could you elaborate please? Again, keep databases out of it, Linq is not a database framework. The fact that you continue to compare Linq to Hibernate shows you think Linq is database related, which just shows your ignorance. Linq has nothing to do with databases.
Lambdas? I haven't seen where they are significantly better than other simpler solutions
You are kidding right? Lambdas are the simple solution, they make code more succinct and to the point than the alternatives. Your statement shows that you think you know best and everybody else is wrong. This just shows a staggering level of ignorance. There is a reason "everybody" wants Lambdas. They make your code better. They are not magical, but succinct code is better than overly verbose code, which the code is when not using lambdas.
You can accept that statement as is or not.
Considering the fact that all you have provided so far is ignorant nonsense (about both lambdas and Linq) I take what you say for what it is. The ramblings of someone who's relevance has come (being nice here) and gone. Probably decades ago.
The Java app was far more modular
So you are not comparing Java to C#/.Net. They two are close to identical in base features, so it is impossible to make a Java app that is more modular than you can make a .Net app. What you are saying above is that you are comparing the code of a bunch of morons who could not make a modular app to the code of competent developers that could. That's the comparison of an ignorant moron. There is nothing in Java that makes it possible to create more modular apps than you could in .Net. Quite the opposite in fact, at the moment, since DI etc is a core part of the .Net framework, it is easier to create modular .Net apps than Java apps out of the box. In Java you first have to figure out, for example, what DI framework to use.
Sometimes bad architecture lays a crumbling foundation that just can't be corrected.
Yeah, but bad architecture is not a framework or language feature. Bad architecture is a feature of the software developers implementing the solution. Using bad developers as an example to illustrate bad frameworks or bad languages is moronic, to put it mildly. If you had any experience as a developer, you would know that.
Java's outperforming C# is based on real world scenarios
No, it is not, and you just said it is not. In real world scenarios nobody in the world has observed what you claim. You are the only one. So, is everybody in the world an idiot and you a genius? Probably not, you are just ignorant. You said that the reason the systems you were struggling with were bad was because of incompetent developers, not a bad framework or a bad language decision. The performance is based on the fact that the developers you are talking about were morons, not that the tools they had selected were bad. Bad architecture creates un-maintainable software, bad architecture will usually result in under-performing software, but that has nothing to do with the tools. Seriously. You can't be this dumb!
A current startup project is still in testing stages, and tables are already touching 1M rows...
If each of those calls hit 5 tables...
So you are talking about relatively small systems with few tables and quite moderate amounts of data. OK. That may explain things. You simply haven't worked on teams where performance is an issue, you have had some straight-out-of-school kids do some stuff in .Net, and you think that you have worked on big data stuff. That's more than just a little sad.
Imagine an MPLS switched network with about 20 000 nodes, switches some servers
If you're talking about LYNC
I assume, since this was in a DB context, you meant Linq, Lync is a messenger thingimajig I believe. Linq is a language feature not a tool, if you don't know what tools are ask a programmer. Oh, and I doubt the number of developers in the .Net world that uses Linq2SQL directly is insignificant, if you are dealing with a DB you're probably using the .Net equivalent to Hibernate, the Entity Framework. The developers of the Entity Framework did learn a thing or two from Hibernate though, and the Entity Framework, though far from perfect, is far less of a clusterfuck than Hibernate is. Still, neither are great for DB apps with significant performance requirements. Entity Framework blows Hibernate out of the water though. Both in performance and usability. Nuclear blast style blows out of the water. Where EF is just not great, Hibernate should actually be banned from the Enterprise, and in many companies where I have worked, it actually is.
Linq on the other hand just another way to write Lambda expressions, in fact, Linq queries are compiled to Lambda expressions by the C# compiler. If Linq is bad then Lambdas are bad. If Lambdas are bad then I am curious as to why the Java community has been begging for them for years. Linq can be used to write lambdas for any collection type. I currently fetch Json from a very, very slow government server somewhere and I use lambdas to parse the data as it comes back. Since the server in question doesn't do any filtering on the data at all, and I'm only interested in about 5% of what it returns, having a single line of code extracting what I need is cool. I can write [obviously it's a tad more complex] var myStuff = allStuff.Where( s => "value".Equals(s.property)); which is quite useful. The code runs once every 24 hours, so I don't really care if it runs in 2ms or 3ms. If performance was critical, I might have written it differently. Why being able to query Json like that would be a bad thing is a mystery to me. Can you elaborate please? Why are lambdas horrible? I could have written it in Linq too (from d in data where d.property == "value" select d) but that would have been more verbose and to me (but that is just preference) less clear. The code is identical though, once it's run through the first compiler step. As a side note - about a year ago that server returned a highly convoluted XML stream instead of Json. The code to filter my data from the XML result didn't change at all. I can query Json, XML, a list of C# objects or a database with the same line of code. As I said, I'm not saying it is hugely performant, but for most Enterprise applications that is actually not an issue.
Now, you can easily argue that Lambdas (and by association Linq) are not performant enough for high-performance applications, and depending on how the lambda implementation for various entities, you would most of the time be correct. So, stay away from them. Linq and Lambdas are great for many types of applications where performance is perhaps important but load is lower.
The Java system easily outperformed the .NET system by a factor of 10:1
Seriously? This comment alone shows that you are lying through your teeth. There isn't a single benchmark in the world that would give a ten to one speed advantage for Java over .Net. Not one. It's pure balderdash.
was updated multiple times for each .NET update cycle
So you claim it is easier to update Java apps than C# apps? That's just nonsense. Fanboi warning. Remember, your programming language is a tool, not a savior of your soul. Get a grip. The similarities between C# and Java are significantly more important than the differences, but C# tooling is far better. Re-factoring, for example, in Visual Studio with Re-Sharper blows the Eclipse variation out of the water, it easily beats IntelliJ too. The fact
Companies that use .NET are not smart
Can you elaborate on why? :Net and C# beats the Java platform in every single way except perhaps one, the Play Framework, which originally was basically .Net MVC ported to Java.
Would be better to use an open source toolkit rather than to make oneself hostage of MS,
Ah, that explains it. You are just clueless. Let''s see, what Open Source tools are .Net comprised of? Well, all of .Net obviously. The C# Compiler too. Is the Java compiler open source? More? Yeah, Visual Studio is free, but it isn't open source, but then again, Visual Studio Code, a very good IDE for just about anything is. Yeah, so ALL the tools I use on my MacBook Pro to develop Angular and Ionic apps with .Net back-ends are in fact open source. Wow. You get the price for the most clueless person still living in the 1990s.