I appreciate IBM's move to buy more Macs for themselves and to provide configured Macs to IBM customers but someone big has to take the leap and decide a Microsoft-centric environment isn't necessary to stay in business before Macs finally become the primary desktop platform.
True, but two things to note about this partnership. First, IBM is, as we all know, HUGE, they alone are one of the largest IT deployments in the world, and from the numbers we're seeing in the articles, will be one of the largest Mac replacement sites. Second, while IBM does sell into the SME/SMB segment, they primarily sell into large public and private organisations with a highly compensated direct sales force, and that (big orgs) is where they make the vast majority of their money. They have the relationships with the biggest orgs in the world (CEO/CFO/CHRO/CMO/CIO/CTOs), for them this must be one of the biggest opportunities facing them, to get into an IT department and sell them a replace your IT hardware/software strategy, "look at us, we did it ourselves, we'll help you achieve the savings we did." In fact, I'd bet this is a CFO led sale, not so much a CIO led one.
Where IBM can use itself as a case study, they willingly do so and they are always a great case study because few companies can point at their first installation and say, "we installed 200K desktop/laptop replacements to one organisation successfully, and we have all the data to share."
I understand this is what's happening right now and that Apple will (probably) never market an OSX Server platform but that doesn't mean IBM couldn't supply a tightly connected OSXServer running on IBM hardware ...
So now IBM is going to be building Hackintoshes? ¡No way José!
The main compelling reasons that I can think of are:
speed -- not only running the app on the server, but transmission speed and performance at the client side (especially mobile)
I don't see how it would be any faster just because it is mobile. Mobile is usually slower compared to a desktop anyway because the CPU is underpowered and there is not a lot of Ram. If we are still talking about web server scripting such as PHP vs. Swift, the only thing that could make one faster than the other is if it can render the page into HTML or return a JSON object faster. I suspect it will be hard to beat PHP because PHP is compiled directly into the Apache binary. Do you think Apple is also going to release a Swift server for Linux? I don't. If Apache has to hand off the rendering to a separate Swift interpreter first and then get it back to service the request, it is going to slower, a lot slower.
Quote:
Apple/IBM certainly could implement DB as native Swift commands.
SQL already has it's own standards compliant language.
I suspect that IBM and Apple's heavy use of Linux servers was instrumental in open-sourcing Swift -- Compiler and standard libraries will be available for OS X, iOS, Watch OS2, and Linux.
I suspect that the Mac OSX operating system in reality is an AIX based operating system with an UI developed by Apple Inc.
I suspect that that the iOS operating system for the iPhone/iPad in reality is the System I operating system (previously OS/400) with an UI developed by Apple Inc (see: IBM System i).
IBM is currently migrating both platforms to only one (see: IBM Power Systems).
I understand this is what's happening right now and that Apple will (probably) never market an OSX Server platform but that doesn't mean IBM couldn't supply a tightly connected OSXServer running on IBM hardware ...
So now IBM is going to be building Hackintoshes? ¡No way José!
I agree -- IBM doesn't sell to SMBs who would be attracted by an OS X server ... They have no dog in this hunt!
The main compelling reasons that I can think of are:
speed -- not only running the app on the server, but transmission speed and performance at the client side (especially mobile)
I don't see how it would be any faster just because it is mobile. Mobile is usually slower compared to a desktop anyway because the CPU is underpowered and there is not a lot of Ram. If we are still talking about web server scripting such as PHP vs. Swift, the only thing that could make one faster than the other is if it can render the page into HTML or return a JSON object faster. I suspect it will be hard to beat PHP because PHP is compiled directly into the Apache binary. Do you think Apple is also going to release a Swift server for Linux? I don't. If Apache has to hand off the rendering to a separate Swift interpreter first and then get it back to service the request, it is going to slower, a lot slower.
Apple/IBM certainly could implement DB as native Swift commands.
SQL already has it's own standards compliant language.
True, but SQL (and its variants) are not necessarily the best data solution for all needs. That's my point.
I understand this is what's happening right now and that Apple will (probably) never market an OSX Server platform but that doesn't mean IBM couldn't supply a tightly connected OSXServer running on IBM hardware (I know they dumped their small server hardware) providing an integrated management system (better than JAMF) with a replacement for AD that doesn't require exorbitant client licenses. As more Macs enter the corporate network, there will be a justification to do this. AD can be configured to work almost well with Macs but Microsoft will never give them everything and OSX just works differently than Windows and Microsoft can't figure out the best way to support them (not in their business plan). If IBM is trying to stay alive by working with Apple, then there needs to be some give and take to help small and larger corporate offices run a Mac shop properly.
As for IBM and Apple running Linux on their systems, so what. IBM already provides the source code to compile their DB2 Express database onto Macs. All that's necessary would be for them to provide a way to host OSX Server, clean up that product, add whatever other IBM services seem reasonable and market a Mac-specific IBM server product. Seems reasonable to me.
OS X Server is not that special!. Almost all of it is just open-source server stuff already built into distributions of Linux -- with an attempt to make it a little more friendly. For a workgroup that does not need much, then just download and configure the OS X server on a Mac Pro.... but for larger shops they will likely have servers anyways... and the knowledge to configure Linux.
It is about getting the biggest bang for the buck.... Don't go overboard in a fanboyish sort of way and try to stuff everything that is not Apple into the garbage just for the sake of it.... you will only scare customers when you display that kind of zealotism because it is no longer about providing the best service to the customer.
It well could be a server scripting language. Based on Lattner's background it seems preordained that Swift will not be just another app programming language. I haven't perused the Swift section of the Apple site recently, but there was a time when they referred to Swift as a System programming language. That could mean anything from a language to write compilers/linkers/runtimes, OSes, to a replacement for low-level Scripts such as OAS (AppleScript) Bash, even some JavaScript.
As to the PHP LLVM question -- they could :
write a SIFT app to convert PHP to Swift
co-exist (share APIs) with PHP ala Objective-C
let the PHP apps run side-by-side until there is a compelling reason to change.
It's been more than 15 years since I did any Web programming. I cut my teeth on JavaScript, then Perl, some PHP, but at then end I mostly used ColdFusion. So I am not current on the State Of The Art of PHP -- IDK if any of the suggestions are practical. What do you think?
As to the compelling reason to rewrite apps in Swift ... I would be amazed if Apple and IBM don't have projects already in place to make that happen (where you can't afford not to change to Swift) . IBM has quite a few Software Engineers that they could hire out to consult/teach/manage/perform the conversions
Systems programming languages basically are highly performant languages (C, C++, Rust) that compile down to binary code and can be used to write systems (Operating Systems). Swift is highly performant. PHP was created by someone that does not like programming and it is one big hack. It is widely used in on the web, and it is widely a security issue on the web. Personally, I would never use it for any substantive project.
Personally I would like Swift to implement more functional paradigm into it's core. I know why it was not a high priority for them -- it is because it's first function was to write UI applications and the UI model for OS X (and most others) is object-oriented. I do like Swift, but I still prefer Scala over Swift as a language - I just wish Scala would divorce the java environment which hampers the language and causes a lot of edge case issues (which 99% of developers will not run into).
So now IBM is going to be building Hackintoshes? ¡No way José!
Quote:
Originally Posted by Dick Applebaum
I agree -- IBM doesn't sell to SMBs who would be attracted by an OS X server ... They have no dog in this hunt!
Quote:
Originally Posted by bkkcanuck
OS X Server is not that special!. Almost all of it is just open-source server stuff already built into distributions of Linux -- with an attempt to make it a little more friendly. For a workgroup that does not need much, then just download and configure the OS X server on a Mac Pro.... but for larger shops they will likely have servers anyways... and the knowledge to configure Linux.
It is about getting the biggest bang for the buck.... Don't go overboard in a fanboyish sort of way and try to stuff everything that is not Apple into the garbage just for the sake of it.... you will only scare customers when you display that kind of zealotism because it is no longer about providing the best service to the customer.
None of you completely understood what I said (or was trying to say). I'm not asking IBM to build a Mac with OSX Server running on it. I'm suggesting IBM build a server product with the critical components and configurations that would work best for Macs, not as an afterthought but as a server that meets the needs of Macs and iOS devices. Yes, OSX Server is a bunch of open source software (but so is linux) but combined with IBM software and configured to run "natively" instead of having someone spend a bunch of time trying to get Macs to function properly, could be a product IBM and Apple could agree on and some companies might even buy. Maybe not but I'm just making a suggestion. I ran a large Mac shop for several years and it ran fine, at least until it was forced to integrate with corporate Windows and unix systems, then it went into the toilet because the corporate IT staff hadn't the faintest idea how to deal with Macs (and didn't care to learn). As far as linux IT people knowing how to configure servers to work with Macs, the ones I had to work with sure didn't.
The sad truth is, many businesses will stick with PCs (Dell, HP) because they feel they're less expensive. The smarter ones will realize the cost of hardware is far from the main factor deciding cost.
That's not true at all. Business PC's from Dell, HP and Lenovo are far better than what you see at retailers, and sometimes better than Apple products. Plus they offer more service options than Apple Care. And they are very similar to Apple in pricing, so I don't think money is an issue in mid / large business or enterprises.
True, but SQL (and its variants) are not necessarily the best data solution for all needs. That's my point.
SQL is a standard which is probably why Foundation DB added it to their key value layer.
Sorry, I've been tag-teaming my computer with my grandson who's making a movie -- Beta El Capitan doesn't help!.
I know that FoundationDB implemented an SQL Layer (SQL Interface) above their hash DB.
Again, it’s been a while since I did any heave SQL programming (MS & Sybase). Has SQL ever resolved the fatal embrace issue::
Part A has a qty of 1 in stock
Part B has a qty of 1 in stock
Customer 1 orders (reserves) the last Part B
Customer 2 orders (reserves) the last Part A
Customer 1, then tries to order (reserve) Part A — but the quantity is zero
Customer 2, then tries to order (reserve) Part B— but the quantity is zero
The main compelling reasons that I can think of are:
speed -- not only running the app on the server, but transmission speed and performance at the client side (especially mobile)
I don't see how it would be any faster just because it is mobile. Mobile is usually slower compared to a desktop anyway because the CPU is underpowered and there is not a lot of Ram. If we are still talking about web server scripting such as PHP vs. Swift, the only thing that could make one faster than the other is if it can render the page into HTML or return a JSON object faster. I suspect it will be hard to beat PHP because PHP is compiled directly into the Apache binary. Do you think Apple is also going to release a Swift server for Linux? I don't. If Apache has to hand off the rendering to a separate Swift interpreter first and then get it back to service the request, it is going to slower, a lot slower.
First the amount of data transmitted — on mobile it is very expensive -- LTE Data rates. HTML is quite inefficient, JavaScript is the pits. XML is about 70-90% overhead … JSON is better, but can easily be 30-50% overhead. So, if you have an app running on a mobile device, say Safari, that uses the LLVM -- why couldn't the web servers take all the crap they dynamically and convert it to LLVM code, download the smaller packet, then execute it on the device. Radical, I know, but think about it!
The main compelling reasons that I can think of are:
speed -- not only running the app on the server, but transmission speed and performance at the client side (especially mobile)
function -- something new that is easy with Swift, but not practical to retrofit into PHP
As to 1) -- I think it was Gruber who reposted an article where some major web sites had an initial page load time of ~60 seconds. That could mean the difference between gaining a customer or the customer just moving on. Much of that was related to the ungodly amount of distracting ads (title bar, side bars), self launching video adds, etc. I think it was Rene Richards at iMore.com who confronted this directly -- mixing the need for ads and the need for performance. We are becoming ever more dependent on our mobile devices -- where speed in not just nice, there can cases where it may be vital (health care, for example).
Java and ASP.NET are both well-established, high-performance alternatives to PHP. Every major website (like your that of your bank) probably uses one or the other for their backend heavy lifting. What advantages would Swift bring as a server-side language over JavaEE?
First the amount of data transmitted — on mobile it is very expensive -- LTE Data rates. HTML is quite inefficient, JavaScript is the pits. XML is about 70-90% overhead … JSON is better, but can easily be 30-50% overhead. So, if you have an app running on a mobile device, say Safari, that uses the LLVM -- why couldn't the web servers take all the crap they dynamically and convert it to LLVM code, download the smaller packet, then execute it on the device. Radical, I know, but think about it!
Methinks IBM is capable of bringing a substantial Mac server and backend infrastructure on the market and make it a success. I hope they will go that way eventually.
IBM is interested in replacing Microsoft as the "go to" source for server HW and IT services, and will do whatever is necessary to make that happen. To that end, replacing Windows boxes with Mac boxes is probably not that big a deal, however if IBM is comfortable with a mixed network and Microsoft isn't, then IBM has an advantage. Furthermore, if most new computers in an enterprise are mobile, then Apple is the way to go for a better experience, and IBM is eager to push that,
First the amount of data transmitted — on mobile it is very expensive -- LTE Data rates. HTML is quite inefficient, JavaScript is the pits. XML is about 70-90% overhead … JSON is better, but can easily be 30-50% overhead. So, if you have an app running on a mobile device, say Safari, that uses the LLVM -- why couldn't the web servers take all the crap they dynamically and convert it to LLVM code, download the smaller packet, then execute it on the device. Radical, I know, but think about it!
What you are talking about is the laziness and lack of thought of implementing a service for remote devices. Back in the days when 9600 bps was the maximum speed for branches to banks back ends you had no choice about being efficient or not. If you were not efficient you were not allowed in the banks IT doors. You don't need HTML, you definitely should never use XML or JSON for communications except when you are for low volume interfaces where the only requirement is ease of implementation and you have unlimited bandwidth and speed. If you send an XML document you are instantiating millions of objects on the server then flushing them down the garbage chute each and every minute. It drives up latency and it is just lazy. Just be more careful in defining your messages between client applications and server and use more efficient messaging formats. Google itself uses: https://developers.google.com/protocol-buffers/?hl=en which are not that bad.
Sorry, I've been tag-teaming my computer with my grandson who's making a movie -- Beta El Capitan doesn't help!.
I know that FoundationDB implemented an SQL Layer (SQL Interface) above their hash DB.
Again, it’s been a while since I did any heave SQL programming (MS & Sybase). Has SQL ever resolved the fatal embrace issue::
Part A has a qty of 1 in stock
Part B has a qty of 1 in stock
Customer 1 orders (reserves) the last Part B
Customer 2 orders (reserves) the last Part A
Customer 1, then tries to order (reserve) Part A — but the quantity is zero
Customer 2, then tries to order (reserve) Part B— but the quantity is zero
What does the SQL DB do?
If you develop an application defectively you will run into situations. It is not just an issue with databases but an underlying subject taught in University in regards to resource usage and conflict resolution.
It really depends on the implementation, but if you require both parts or none.... there are several ways to deal with situation through locking (optimistically or not) then if resources are not available failing. Hieratically you would process them in a consistent order. It is just a matter of how you manage transactions. Never really had any issues where this is a problem and I have worked on large financial transactional systems.
The main compelling reasons that I can think of are:
speed -- not only running the app on the server, but transmission speed and performance at the client side (especially mobile)
function -- something new that is easy with Swift, but not practical to retrofit into PHP
As to 1) -- I think it was Gruber who reposted an article where some major web sites had an initial page load time of ~60 seconds. That could mean the difference between gaining a customer or the customer just moving on. Much of that was related to the ungodly amount of distracting ads (title bar, side bars), self launching video adds, etc. I think it was Rene Richards at iMore.com who confronted this directly -- mixing the need for ads and the need for performance. We are becoming ever more dependent on our mobile devices -- where speed in not just nice, there can cases where it may be vital (health care, for example).
Java and ASP.NET are both well-established, high-performance alternatives to PHP. Every major website (like your that of your bank) probably uses one or the other for their backend heavy lifting. What advantages would Swift bring as a server-side language over JavaEE?
I can't answer that question as I have no ASP.NET Experience and very little Java experience. When Swift was announced, it was presented as an amalgam of the best capabilities of many modern languages implemented to provide code safety, performance, conciseness (readability/maintainability), etc. There must be a need for for some of this because of the dramatic rise in popularity of Swift in a very short time.
Sorry, I've been tag-teaming my computer with my grandson who's making a movie -- Beta El Capitan doesn't help!.
I know that FoundationDB implemented an SQL Layer (SQL Interface) above their hash DB.
Again, it’s been a while since I did any heave SQL programming (MS & Sybase). Has SQL ever resolved the fatal embrace issue:
Part A has a qty of 1 in stock
Part B has a qty of 1 in stock
Customer 1 orders (reserves) the last Part B
Customer 2 orders (reserves) the last Part A
Customer 1, then tries to order (reserve) Part A — but the quantity is zero
Customer 2, then tries to order (reserve) Part B— but the quantity is zero
What does the SQL DB do?
If you develop an application defectively you will run into situations. It is not just an issue with databases but an underlying subject taught in University in regards to resource usage and conflict resolution.
It really depends on the implementation, but if you require both parts or none.... there are several ways to deal with situation through locking (optimistically or not) then if resources are not available failing. Hieratically you would process them in a consistent order. It is just a matter of how you manage transactions. Never really had any issues where this is a problem and I have worked on large financial transactional systems.
Man, you made me chuckle: It depends on the implementation -- I don't know how many times I used those same words when I worked for IBM.
From the way you answered the question, I assume that a modern SQL DB does nothing to detect or resolve the situation. If that is true, then both customer's transactions, in my example, will fail (timeout) with possible locks in place and the DB will have quantities reserved that were not sold. This will require some application code to cleanup the DB.
An even more frustrating case can happen for the customer who already has a product reserved and can't reserve another. Even if the app detects the fatal embrace , likely, the transaction fails and is backed out by the app -- the customer has lost the product reservation he had and it is now out of stock. The customer was never allowed to switch his second request to a different item to avoid the deadlock. I'm looking at you Apple Online Store!
I know that it is not just an issue with databases -- but I suspect that databases are a major cause of the issue. My point is that the database and the programming language can do a lot more to rigorously confront and resolve the situation in a consistent manner.
Comments
I appreciate IBM's move to buy more Macs for themselves and to provide configured Macs to IBM customers but someone big has to take the leap and decide a Microsoft-centric environment isn't necessary to stay in business before Macs finally become the primary desktop platform.
True, but two things to note about this partnership. First, IBM is, as we all know, HUGE, they alone are one of the largest IT deployments in the world, and from the numbers we're seeing in the articles, will be one of the largest Mac replacement sites. Second, while IBM does sell into the SME/SMB segment, they primarily sell into large public and private organisations with a highly compensated direct sales force, and that (big orgs) is where they make the vast majority of their money. They have the relationships with the biggest orgs in the world (CEO/CFO/CHRO/CMO/CIO/CTOs), for them this must be one of the biggest opportunities facing them, to get into an IT department and sell them a replace your IT hardware/software strategy, "look at us, we did it ourselves, we'll help you achieve the savings we did." In fact, I'd bet this is a CFO led sale, not so much a CIO led one.
Where IBM can use itself as a case study, they willingly do so and they are always a great case study because few companies can point at their first installation and say, "we installed 200K desktop/laptop replacements to one organisation successfully, and we have all the data to share."
I understand this is what's happening right now and that Apple will (probably) never market an OSX Server platform but that doesn't mean IBM couldn't supply a tightly connected OSXServer running on IBM hardware ...
So now IBM is going to be building Hackintoshes? ¡No way José!
The main compelling reasons that I can think of are:
I don't see how it would be any faster just because it is mobile. Mobile is usually slower compared to a desktop anyway because the CPU is underpowered and there is not a lot of Ram. If we are still talking about web server scripting such as PHP vs. Swift, the only thing that could make one faster than the other is if it can render the page into HTML or return a JSON object faster. I suspect it will be hard to beat PHP because PHP is compiled directly into the Apache binary. Do you think Apple is also going to release a Swift server for Linux? I don't. If Apache has to hand off the rendering to a separate Swift interpreter first and then get it back to service the request, it is going to slower, a lot slower.
SQL already has it's own standards compliant language.
I suspect that IBM and Apple's heavy use of Linux servers was instrumental in open-sourcing Swift -- Compiler and standard libraries will be available for OS X, iOS, Watch OS2, and Linux.
I suspect that the Mac OSX operating system in reality is an AIX based operating system with an UI developed by Apple Inc.
(see: IBM System p).
I suspect that that the iOS operating system for the iPhone/iPad in reality is the System I operating system (previously OS/400) with an UI developed by Apple Inc (see: IBM System i).
IBM is currently migrating both platforms to only one (see: IBM Power Systems).
I agree -- IBM doesn't sell to SMBs who would be attracted by an OS X server ... They have no dog in this hunt!
True, but SQL (and its variants) are not necessarily the best data solution for all needs. That's my point.
True, but SQL (and its variants) are not necessarily the best data solution for all needs. That's my point.
SQL is a standard which is probably why Foundation DB added it to their key value layer.
I understand this is what's happening right now and that Apple will (probably) never market an OSX Server platform but that doesn't mean IBM couldn't supply a tightly connected OSXServer running on IBM hardware (I know they dumped their small server hardware) providing an integrated management system (better than JAMF) with a replacement for AD that doesn't require exorbitant client licenses. As more Macs enter the corporate network, there will be a justification to do this. AD can be configured to work almost well with Macs but Microsoft will never give them everything and OSX just works differently than Windows and Microsoft can't figure out the best way to support them (not in their business plan). If IBM is trying to stay alive by working with Apple, then there needs to be some give and take to help small and larger corporate offices run a Mac shop properly.
As for IBM and Apple running Linux on their systems, so what. IBM already provides the source code to compile their DB2 Express database onto Macs. All that's necessary would be for them to provide a way to host OSX Server, clean up that product, add whatever other IBM services seem reasonable and market a Mac-specific IBM server product. Seems reasonable to me.
OS X Server is not that special!. Almost all of it is just open-source server stuff already built into distributions of Linux -- with an attempt to make it a little more friendly. For a workgroup that does not need much, then just download and configure the OS X server on a Mac Pro.... but for larger shops they will likely have servers anyways... and the knowledge to configure Linux.
It is about getting the biggest bang for the buck.... Don't go overboard in a fanboyish sort of way and try to stuff everything that is not Apple into the garbage just for the sake of it.... you will only scare customers when you display that kind of zealotism because it is no longer about providing the best service to the customer.
It well could be a server scripting language. Based on Lattner's background it seems preordained that Swift will not be just another app programming language. I haven't perused the Swift section of the Apple site recently, but there was a time when they referred to Swift as a System programming language. That could mean anything from a language to write compilers/linkers/runtimes, OSes, to a replacement for low-level Scripts such as OAS (AppleScript) Bash, even some JavaScript.
As to the PHP LLVM question -- they could :
It's been more than 15 years since I did any Web programming. I cut my teeth on JavaScript, then Perl, some PHP, but at then end I mostly used ColdFusion. So I am not current on the State Of The Art of PHP -- IDK if any of the suggestions are practical. What do you think?
As to the compelling reason to rewrite apps in Swift ... I would be amazed if Apple and IBM don't have projects already in place to make that happen (where you can't afford not to change to Swift) . IBM has quite a few Software Engineers that they could hire out to consult/teach/manage/perform the conversions
Systems programming languages basically are highly performant languages (C, C++, Rust) that compile down to binary code and can be used to write systems (Operating Systems). Swift is highly performant. PHP was created by someone that does not like programming and it is one big hack. It is widely used in on the web, and it is widely a security issue on the web. Personally, I would never use it for any substantive project.
Personally I would like Swift to implement more functional paradigm into it's core. I know why it was not a high priority for them -- it is because it's first function was to write UI applications and the UI model for OS X (and most others) is object-oriented. I do like Swift, but I still prefer Scala over Swift as a language - I just wish Scala would divorce the java environment which hampers the language and causes a lot of edge case issues (which 99% of developers will not run into).
So now IBM is going to be building Hackintoshes? ¡No way José!
I agree -- IBM doesn't sell to SMBs who would be attracted by an OS X server ... They have no dog in this hunt!
OS X Server is not that special!. Almost all of it is just open-source server stuff already built into distributions of Linux -- with an attempt to make it a little more friendly. For a workgroup that does not need much, then just download and configure the OS X server on a Mac Pro.... but for larger shops they will likely have servers anyways... and the knowledge to configure Linux.
It is about getting the biggest bang for the buck.... Don't go overboard in a fanboyish sort of way and try to stuff everything that is not Apple into the garbage just for the sake of it.... you will only scare customers when you display that kind of zealotism because it is no longer about providing the best service to the customer.
None of you completely understood what I said (or was trying to say). I'm not asking IBM to build a Mac with OSX Server running on it. I'm suggesting IBM build a server product with the critical components and configurations that would work best for Macs, not as an afterthought but as a server that meets the needs of Macs and iOS devices. Yes, OSX Server is a bunch of open source software (but so is linux) but combined with IBM software and configured to run "natively" instead of having someone spend a bunch of time trying to get Macs to function properly, could be a product IBM and Apple could agree on and some companies might even buy. Maybe not but I'm just making a suggestion. I ran a large Mac shop for several years and it ran fine, at least until it was forced to integrate with corporate Windows and unix systems, then it went into the toilet because the corporate IT staff hadn't the faintest idea how to deal with Macs (and didn't care to learn). As far as linux IT people knowing how to configure servers to work with Macs, the ones I had to work with sure didn't.
The sad truth is, many businesses will stick with PCs (Dell, HP) because they feel they're less expensive. The smarter ones will realize the cost of hardware is far from the main factor deciding cost.
That's not true at all. Business PC's from Dell, HP and Lenovo are far better than what you see at retailers, and sometimes better than Apple products. Plus they offer more service options than Apple Care. And they are very similar to Apple in pricing, so I don't think money is an issue in mid / large business or enterprises.
Sorry, I've been tag-teaming my computer with my grandson who's making a movie -- Beta El Capitan doesn't help!.
I know that FoundationDB implemented an SQL Layer (SQL Interface) above their hash DB.
Again, it’s been a while since I did any heave SQL programming (MS & Sybase). Has SQL ever resolved the fatal embrace issue::
Part A has a qty of 1 in stock
Part B has a qty of 1 in stock
Customer 1 orders (reserves) the last Part B
Customer 2 orders (reserves) the last Part A
Customer 1, then tries to order (reserve) Part A — but the quantity is zero
Customer 2, then tries to order (reserve) Part B— but the quantity is zero
What does the SQL DB do?
First the amount of data transmitted — on mobile it is very expensive -- LTE Data rates. HTML is quite inefficient, JavaScript is the pits. XML is about 70-90% overhead … JSON is better, but can easily be 30-50% overhead. So, if you have an app running on a mobile device, say Safari, that uses the LLVM -- why couldn't the web servers take all the crap they dynamically and convert it to LLVM code, download the smaller packet, then execute it on the device. Radical, I know, but think about it!
The main compelling reasons that I can think of are:
As to 1) -- I think it was Gruber who reposted an article where some major web sites had an initial page load time of ~60 seconds. That could mean the difference between gaining a customer or the customer just moving on. Much of that was related to the ungodly amount of distracting ads (title bar, side bars), self launching video adds, etc. I think it was Rene Richards at iMore.com who confronted this directly -- mixing the need for ads and the need for performance. We are becoming ever more dependent on our mobile devices -- where speed in not just nice, there can cases where it may be vital (health care, for example).
Java and ASP.NET are both well-established, high-performance alternatives to PHP. Every major website (like your that of your bank) probably uses one or the other for their backend heavy lifting. What advantages would Swift bring as a server-side language over JavaEE?
First the amount of data transmitted — on mobile it is very expensive -- LTE Data rates. HTML is quite inefficient, JavaScript is the pits. XML is about 70-90% overhead … JSON is better, but can easily be 30-50% overhead. So, if you have an app running on a mobile device, say Safari, that uses the LLVM -- why couldn't the web servers take all the crap they dynamically and convert it to LLVM code, download the smaller packet, then execute it on the device. Radical, I know, but think about it!
See also http://arstechnica.com/information-technology/2015/06/the-web-is-getting-its-bytecode-webassembly/
Methinks IBM is capable of bringing a substantial Mac server and backend infrastructure on the market and make it a success. I hope they will go that way eventually.
IBM is interested in replacing Microsoft as the "go to" source for server HW and IT services, and will do whatever is necessary to make that happen. To that end, replacing Windows boxes with Mac boxes is probably not that big a deal, however if IBM is comfortable with a mixed network and Microsoft isn't, then IBM has an advantage. Furthermore, if most new computers in an enterprise are mobile, then Apple is the way to go for a better experience, and IBM is eager to push that,
First the amount of data transmitted — on mobile it is very expensive -- LTE Data rates. HTML is quite inefficient, JavaScript is the pits. XML is about 70-90% overhead … JSON is better, but can easily be 30-50% overhead. So, if you have an app running on a mobile device, say Safari, that uses the LLVM -- why couldn't the web servers take all the crap they dynamically and convert it to LLVM code, download the smaller packet, then execute it on the device. Radical, I know, but think about it!
What you are talking about is the laziness and lack of thought of implementing a service for remote devices. Back in the days when 9600 bps was the maximum speed for branches to banks back ends you had no choice about being efficient or not. If you were not efficient you were not allowed in the banks IT doors. You don't need HTML, you definitely should never use XML or JSON for communications except when you are for low volume interfaces where the only requirement is ease of implementation and you have unlimited bandwidth and speed. If you send an XML document you are instantiating millions of objects on the server then flushing them down the garbage chute each and every minute. It drives up latency and it is just lazy. Just be more careful in defining your messages between client applications and server and use more efficient messaging formats. Google itself uses: https://developers.google.com/protocol-buffers/?hl=en which are not that bad.
Sorry, I've been tag-teaming my computer with my grandson who's making a movie -- Beta El Capitan doesn't help!.
I know that FoundationDB implemented an SQL Layer (SQL Interface) above their hash DB.
Again, it’s been a while since I did any heave SQL programming (MS & Sybase). Has SQL ever resolved the fatal embrace issue::
Part A has a qty of 1 in stock
Part B has a qty of 1 in stock
Customer 1 orders (reserves) the last Part B
Customer 2 orders (reserves) the last Part A
Customer 1, then tries to order (reserve) Part A — but the quantity is zero
Customer 2, then tries to order (reserve) Part B— but the quantity is zero
What does the SQL DB do?
If you develop an application defectively you will run into situations. It is not just an issue with databases but an underlying subject taught in University in regards to resource usage and conflict resolution.
It really depends on the implementation, but if you require both parts or none.... there are several ways to deal with situation through locking (optimistically or not) then if resources are not available failing. Hieratically you would process them in a consistent order. It is just a matter of how you manage transactions. Never really had any issues where this is a problem and I have worked on large financial transactional systems.
I can't answer that question as I have no ASP.NET Experience and very little Java experience. When Swift was announced, it was presented as an amalgam of the best capabilities of many modern languages implemented to provide code safety, performance, conciseness (readability/maintainability), etc. There must be a need for for some of this because of the dramatic rise in popularity of Swift in a very short time.
Man, you made me chuckle: It depends on the implementation -- I don't know how many times I used those same words when I worked for IBM.
From the way you answered the question, I assume that a modern SQL DB does nothing to detect or resolve the situation. If that is true, then both customer's transactions, in my example, will fail (timeout) with possible locks in place and the DB will have quantities reserved that were not sold. This will require some application code to cleanup the DB.
An even more frustrating case can happen for the customer who already has a product reserved and can't reserve another. Even if the app detects the fatal embrace , likely, the transaction fails and is backed out by the app -- the customer has lost the product reservation he had and it is now out of stock. The customer was never allowed to switch his second request to a different item to avoid the deadlock. I'm looking at you Apple Online Store!
I know that it is not just an issue with databases -- but I suspect that databases are a major cause of the issue. My point is that the database and the programming language can do a lot more to rigorously confront and resolve the situation in a consistent manner.