IE has already sandboxing since IE8 (on Vista onwards). Spartan is forked of the (former) IE12's "Edge" trident code. It's basically a new WinRuntime based GUI app that uses the refactored trident engine (with old legacy compatibility code removed).
It'll be interesting to see if MS can stand strong on no backwards-compatibility. It seems like every time they release something new, by the time it's out of beta it's got tons of compatibility baggage added.
I know what you mean. But in this specific case they are continuing to offer the "legacy" IE engine for those jobs, so they may be able to keep this one unencumbered just by pointing people to that.
They sure chose a distracting snapshot of their website to showcase the minimalist UI of this new browser. all I notice at first glance is the alarming "Top Post" and all of the images. I guess this is a good thing?
For what it's worth, recent versions of IE are already evergreen and auto-update by default.
The real culprit behind us still having to support IE8 for some clients is your average enterprise IT department. They'll find ways to lock down updates on any browser. Just as some IT departments have auto updates locked down on Chrome/Firefox already, they'll probably demand a way to do that with Microsoft's browsers too (or find a way to block the updates without Microsoft's support).
I ask every enterprise I walk into what the patch management strategy is. There's always herds of testing, that often takes months. Recommendation? Patch first, deal with compatibility later. In most cases (note, not all) being hacked is more expensive than a temporary, self-imposed denial of service.
Edit: Thing I forgot to add is that an aggressive patch management strategy just so happens to do great things for technical debt.
The thing that makes my life difficult is that even if you (and I) choose not to work directly with/for those laggard companies, their locked down userbase is still on the web and impacts the requirements of sites I build for completely unrelated clients.
On another board, people are all excited about this but I said they need to take a wait and see and "I'm from Missouri, show me" attitude. Microsoft has not shown they can produce a standards compliant browser on par with the others and, so far, the article points out it isn't even level with IE11. And it is this same hype for every version of IE for the past 10 years that we've all been told the same thing, "This one will be the best!".
if it will truly be evergreen as they promise, then it doesnt need to roll out completely bug-free, because things will hopefully get fixed/patched continuously.
i'll take that over the inter-windows-release stagnation and long tail legacy support we have to deal with today.
It's way beyond IE11, what the article was referring to is the score of the IE11 version running with all the optional flags of the Edge rendering engine, which you can't configure in Spartan yet.
Honestly I think it'll have surpassed Firefox before the beta of Windows 10 finishes.
Annotations are a actually great idea if they are all in cloud by default and attached with my social IDs. Then I can follow friends, family and people and view their annotations on web pages as I surf the web. For example, I'm visiting a restaurant website and my friend already annotated with menu recommendation or better direction. The feature can turn every web page in to a wiki. That would be a killer feature that can get viral.
MS actually did this already like 15 years ago. It may have been an Intranet-oriented thing. The end result was that users could add notes to pages. I think it died off with the rest of the Office-web thingies.
I remember an SP2003 installation with thousands of sub portal sites, hundreds of GB (blobs) stored in SQL server. What I really don't understand is the almost non-existing upgrade paths (between versions '01, '03, '07, '10, '13) and the URL-hell (IIS URL alias would solve that).
But in order for annotation to become a thing, don't they need to be integrated into most browsers ? And the annotation extension that supports all browsers will win once this becomes popular ?
I tried creating 'Peanut Gallery' about a decade ago. The main issues then were trying to figure out the best interface that could work across browsers.
I also didn't know how to scale the solution up to allow it to work on every web page for every users.
Also, I anticipated that there would be lots of privacy concerns as you'd basically be collecting every web page a user went to.
1. Scaling this would be a combination of selecting the right data store that would scale linearly on performance as well as on storage costs. There are many.
2. If you were concerned about privacy issues by exposing URLs, you would simply do the following: a) pass URLs only as hashes of the original text, b) have a policy of only storing URLs if they contained annotations
1. What data store can scale linearly on performance and storage (with no bounds)? I'm not sure it exists (or is even possible). We decided on horizontal partitioning with hashed URLs/IPs as the key.
2. We also wanted to provide real-time stats for pages, sites, and hosts. This requires IDing the user and page in a reversible way. Even if it's not reversible, you could easily use a rainbow table to reverse, especially with the limited IPv4 namespace.
However, it seems that such URL collection isn't too big of a concern among the general population.
You also have to maintain plugins or extensions across all the major browsers, which is a pain.
This was a project I was working on before completing a CS degree and/or getting exposure to some of the solutions that could be used. I'd be interested in exploring it again, but I have a few more interesting projects on the stack for now.
Cassandra when done correctly, will scale linearly[0]. As will most other Dynamo type data stores.
Additionally, there are many other large databases (Hadoop, etc) that will scale linearly. While it may not be ideal for this use case, but a proper multi-master setup with many read slaves in either PostgreSQL or MySQL could be described as being able to scale linearly to some unspecified extremely large upper limit (see work done previously at Yahoo, Google, Amazon, et al). Much of this also depends on what you define as scaling linearly (are you looking for linear scaling for memory, reads, writes, storage, latency, costs, etc?).
Real time stats for pages, sites, hosts for a shared annotation system across browsers doesn't mesh well with your initial condition of "privacy concerns."
The Cassandra benchmarks were only for ~1 million writes/sec. I think you'd need to support around 1 billion writes/sec for this application. I think it's possible.
The "privacy concerns" weren't necessarily my own, I just anticipated that others might have them and therefore not adopt the system. For me, the point was to share what sites you were visiting because you'd be annotating (well, chat/message-boarding) those sites with others. Additionally, I thought it would be cool to see who was where at a given time, what sites were popular, or which pages people found particularly interesting (interesting enough to visit anyway) at any given time.
You get diminishing returns, of course, on any kind of technology. You would just basically partition this data out to a 1000 different clusters then, each capable of supporting 1 million writes/second. That would be done through an algorithm along the lines of this:
really don't think this would be an issue, or even a concern, as 1 billion writes per second are "Google-levels" of writes. One would likely run out of financial resources supporting an expansion of 86 terrabytes / day (assuming 1kb minimum new data per write), far faster than you would ever max out the capabilities of the technology.
It's more a finance/business exercise to determine if revenue inflows would actually meet, cover, or exceed revenue outflows on a project like this. You can always make the technology scale and meet the demand.
relies on friends and family sharing similar interests, etc. also same geo space.
hereby super limited in reality.
and if it's people then you just invented comments. which are toxic most of the time. also invented (rap)genius. congrats, millions of funding for you.
I just hope that times when freezing of IE meant that whole OS got frozen too are over. Anyway the design is very clear. They had to redisign it this way because whole Modern UI (metro) is based on minimalism, simple shapes and typography and MS will for sure try to include this browser in Win 10 mobile version. But I'm afraid of plugins which can totally ruin the fresh look and also other things like bookmarks... Anyway if in MS they want to get back on the top then they have to do their best and I guess they know that and attractive design can't solve everything. Mozilla and Chrome are really tough competitors.
Yes, disabling 3rd party cookies is one of the few options in the settings flyout. (There's under 20 settings, total.) The cookies setting is as prominent as Do Not Track and Block pop-ups.
Also, don't think that somehow just disabling third party cookies is going to make you untrackable or prevent you from being thrown to advertisers.
Good to see the option is there. I know it's nothing like a perfect safety net against tracking, but when the option is missing, it's a great sign that the company doesn't care at all about user privacy.
Also, 3rd party cookie disabling is very difficult to do elsewhere - you can set up a proxy server to filter requests & responses but it has no easy way to determine 1st/3rd party requests.
It already is for me. I had to spend ~2-3 days recently debugging IE11's utterly abysmal dom performance and stylesheet performance. Smooth as butter on chrome, 4 FPS on IE. The only way to fix it was to display: none everything I could, and we're only talking about a few hundred dom elements.
Microsoft's biggest issue here is that there is no such thing as a "modern" browser that runs only on one unreleased platform (Windows), that is closed source, and that cannot also run on mobile devices with significant market share (iOS, Android). Regardless of how polished, fast, and great Microsoft makes this, without the above it will never be a "modern" browser, nor gain any significant market share, simply because developers won't support it.
One of the primary reasons why Microsoft needs to immediately halt, backpedal and release a version that can run on Linux/OSX (beyond the obvious need to port to Android/iOS) is that so many high quality sites are tested using automated testing suites (through Selenium, or otherwise), and those testing instances typically run through bash shells / scripts. While I'm sure you could jury-rig Windows 10 to do that (I've used bash on Windows previously, via Git Bash), you would need to rewrite extensive build and testing tool chains to use non-Unix-y commands --- and even then, you'll likely find many of the open source libraries you rely on are broken, unmaintained, or otherwise unusable on Windows.
As an anecdote, and fairly recently, I actually tried getting unit tests for a pre-existing, fairly sizable project with 10s of developers and many hundreds of thousands of lines of code to run on Windows, and realized it was cheaper to just hand all the developers Mac Books than to either train them on installing Unix tool chains on Windows, or on "properly" using Linux -- especially considering they were not responsible to write the unit tests, just run them. It's also much easier to cross-build for Windows from a Unix system, thus it was possible to completely eliminate Windows in the release process almost completely, other than for later manual testing/verification that can't be automated anyways.
It's been clear for a while that 'modern browser' is basically defined as 'browser not made by Microsoft'. That you're willing to define 'modern browser' as basically "must run on iOS and be scriptable from bash" as a way to exclude their latest effort just implies Microsoft is doomed to forever fail your 'true scotsman' test. If they provided a Linux and android port, you'd find something else to exclude them on - modern browsers render their type using TypeKit, after all.
Actually, no. If they provide cross-platform support, open source it, and make it easily pluggable into existing scripting toolchains (ie, Selenium WebDriver or some such), then I'll call it a modern and open browser. Open source isn't actually necessary, so long as its easily installable using native package managers so that SysAdmins don't have to run/write custom installation scripts for CI support.
I honestly couldn't care much if they supported Android or iOS. I'm simply pointing out that the competition -- Chrome, Firefox, Opera -- all have these features, and are what people consider "modern." You can't go backwards on featureset and still be considered modern.
I'm curious - did Apple make available easy toolchains for integrating Safari on iOS into selenium webdriver tests? Or did the Selenium community do that?
Of course, your argument would be that of course Safari on iOS has a large mobile market share, so it qualifies as 'modern', in spite of the fact that it doesn't run on a UNIX system that can be easily scripted.
But are you going to really argue that Windows doesn't represent a significant marketshare of users?
If you're willing to buy all your windows developers macbooks to help them run unit tests, what's to stop you ordering all your UNIX developers a windows laptop to host windows-only browsers running tests driven through a remote webdriver just like the ones that you run on iOS devices?
> realized it was cheaper to just hand all the developers Mac Books than to either train them on installing Unix tool chains on Windows, or on "properly" using Linux
Did you try Cmder? That gets you a pretty reasonable bash environment on Windows with a single install that's dead simple.
Unless it has changed, Cmder is just simply a VTTY for Windows, similar to/replacing cmd.exe from Microsoft. I don't believe it includes, out-of-the-box support for Unix tool chains. You would need to install Cygwin tools, or similar, to accomplish that. If you've ever tried to administer large groups of systems with Cygwin installed, then you've shared my pain.
The quickest, fastest way that I know to get the Unix shell commands/stuff up on Windows is to use the packaged Git installation (which I referenced in my previous post), but the issue then is that if you have ever dealt with semi-large code bases that involve one or two separate programming languages, then every developer has to track down all the various packages (if they exist), build them, or otherwise install / get them to work. This is often why in companies Windows devs are just given a shell account on a central Linux server to run their unit tests, or runs them inside a VM on Windows. Windows doesn't have any kind of central package manager akin to apt / yum / port for Unix systems that would allow for easy and quick installation of widely used open source software. While they are trying to push their own package manager on Windows, I don't see that as being successful anytime soon.
And, ultimately this approach (of installing Unix toolchains on Windows) is just a hackish workaround, and doesn't address the root issue that the most powerful automation toolsets in the world are all written / developed on / designed for Unix-like systems, and they simply do not run natively on Windows. If Microsoft genuinely wants to join the modern development ecosystem, they will provide cross platform versions of their browser and keep them synced and up to date across platforms, so that they can be plugged into the existing infrastructure (and thus investment) companies have made in their development environments, automated testing, and continuous integration/deployment.
Microsoft can not ignore (by virtue of exclusion) Linux / OSX (and other Unix-es) if they want wide-spread adoption of this new Spartan browser, simply because they want to push the Windows platform. That strategy may have worked in the late 90s, early 2000s when there was no other options for a readily usable, simple user experience desktop platform , but that's not the case any more.
You can choose either Cmder by itself or a bundled installer that includes msysgit. I set my default "new console" to that bundled bash and things work pretty great. Start + "cmd" and I'm at a bash prompt in a fairly nice console emulator.
Most people install a better terminal emulator to replace OS X's default terminal app anyway, so we're all installing something to get a nice experience. I really haven't missed any of my Mac's command line friendliness when on my Windows machines using Cmder.
Chocolatey is a fairly popular apt/yum equivalent on Windows. Most anything built on Node, like npm, bower, or jspm, works fine too.
Could things be better? Sure. Every platform has room for improvement in areas. As a developer primarily using Windows here, my day-to-day experience just doesn't seem anywhere nearly as bleak as you're describing though.
I didn't say it was bleak. The difference is that on Linux/OSX you don't need to install extra tools like mysysgit/cgywin or a different terminal emulator (ie, Cmndr or other 'Terminal' replacement on OSX), because the toolset is already there (bash, awk, sed, etc).
Also, the thing here is that it's not optimal, and there's also non-trivial licensing costs when building large continuous integration/deployment systems. Additionally, I don't believe you would be very supportive of the experience on Windows if you were more familiar with what is possible on Linux, OSX or any other Unix, and if you had strong understanding/knowledge/command of the toolsets available on those ecosystems.
There is nothing fundamentally wrong with using Windows as a regular desktop environment (I'm forced to almost every day). It's actually a fairly good experience (from a desktop perspective), but it doesn't give developers and system admins true, powerful out of the box toolsets. For instance, installing PostgreSQL/MySQL/Apache/Nginx/or whatever on Windows is extremely painful, cumbersome, and not standardized across systems. Conversely, compare this: (yum|apt-get|port) install (postgresql|mysql|apache|nginx).
To do proper automation on large sets of Windows systems, you need Windows Server, Active Directory, and Domains properly setup configured, and licensed, especially if you have any kind of security policy and need to push / control updates from a central server and keep strict control of / standardized versions across systems (for instance, in a strict, actually PCI compliant environment). Why bother with any of that when all of that mess / problem is taken care of by your distribution (OSX/Linux/etc), as one would expect it to be. There's no dependency graphs with large sets of Unix-likes, unlike in the Windows ecosystem -- and that really is the main issue here.
> The difference is that on Linux/OSX you don't need to install extra tools like mysysgit/cgywin or a different terminal emulator (ie, Cmndr or other 'Terminal' replacement on OSX), because the toolset is already there (bash, awk, sed, etc).
Of course you're right that things like bash aren't present on a fresh install of Windows. I just don't see much issue with needing to run one Cmder install though, because I know almost no one who uses the built-in terminal app on OS X either. Installing your preferred terminal is somewhere around step 2, after installing your preferred browser. At that point, it's a wash.
> Additionally, I don't believe you would be very supportive of the experience on Windows if you were more familiar with what is possible on Linux, OSX or any other Unix, and if you had strong understanding/knowledge/command of the toolsets available on those ecosystems.
That's a huge assumption. Over the years, I've spent a ton of time with everything from DOS 1.0, to the Amiga CLI + REXX, to Solaris and AIX, to Slackware/RedHat/Ubuntu, to OS X, and to Windows. I first learned assembly on SGI Indigos running Irix and first accessed the web via Mosaic running on SPARCstations. I feel fairly confident in my perspective when it comes to the nuances of various platforms, but I currently prefer Windows.
I mean this in the least confrontational way possible, but that's precisely the kind of off puttingly patronizing "you'd understand if you didn't use Windows" shtick I often see from Mac/Linux users that motivates me to comment on these threads.
Heck, just last weekend I was ripping a buggy apt-installed xcache out of the Ubuntu/Linode apache server that hosts my blog and replacing it with a compiled .so to fix a bizarre edge case where xcache was breaking one of my WordPress plugins (and sucked up two weeks, on and off, of debugging with the plugin's author). In my experience, these type of opaque problems are tremendously more common on *nix than on a modern Windows Server.
BTW, I use ssh from the Cmder command line when I log in to that Linode VPS, just like you might from the command line on any other platform.
> For instance, installing PostgreSQL/MySQL/Apache/Nginx/or whatever on Windows is extremely painful, cumbersome, and not standardized across systems. Conversely, compare this: (yum|apt-get|port) install (postgresql|mysql|apache|nginx).
Come on. No one who has ever installed any of those things in production would pretend it's so simple. You're going to spend so much time on configuration that the difference between apt-get and running an .msi is negligible.
>> For instance, installing PostgreSQL/MySQL/Apache/Nginx/or whatever on Windows is extremely painful, cumbersome, and not standardized across systems. Conversely, compare this: (yum|apt-get|port) install (postgresql|mysql|apache|nginx).
> Come on. No one who has ever installed any of those things in production would pretend it's so simple. You're going to spend so much time on configuration that the difference between apt-get and running an .msi is negligible.
Actually, no. This discussion is about development and configuration of a workstation for development and the necessity to have the developers run the same unit tests that also need to run the same on the integration servers (not Windows). For the vast majority of cases, actually yes, all one needs is a apt-get/yum/port install of the package dependencies and that's it -- most if not all "out of the box" configuration for most developers will work just fine for the development environment (ie, the developer's workstation). Additionally, those system package managers provide a much simpler and easier way for a developer to manage system updates (have you ever used Windows update? it's unbelievably slow).
And, to your above reference, re: Ubuntu, while I've personally never had any issues with using Ubuntu as a production server, I wouldn't recommend doing that (and do not use it where I have direct authority/control or choice), because for production one would want 'debian stable' (and is what I have recommended for years). One would not want a headless server environment to use Ubuntu, as the differences that make 'Ubuntu' vs 'debian testing' are primarily downstream additions that are only good/applicable to the desktop and do nothing to help the underlying stability of the system.
To emphasize here, I am not discussing simple one-off Wordpress deployments for your hobbyist blog that likely no one reads, and that you most likely don't even need xcache for. I highly doubt you have the traffic volumes wherein xcache would actually show significant improvement/performance over nothing at all (do you even understand what xcache does?). And if you did, you should likely move on to HHVM (which, btw, is production ready, and works out of the box for the most popular distributions).
Quite frankly, the fact that you are discussing compiling a .so for xcache on Ubuntu shows just how far behind the time you are on the state of Ubuntu and PHP as there are working xcache apt repositories that you can use quite simply, please see: https://www.dotdeb.org/ . Your anecdotal failure of having a problem building a single .so (which you shouldn't have been wasting time compiling yourself anyways), is only representative of your particular issues and is not at all representative of how software is actually used, developed, tested, and deployed in large, significant (monetarily, culturally, politically, etc) systems.
Additionally, the most basic "best practices" for system administration would call for the use of packages wherever possible. Manually compiling extensions (or other dependencies) that you did not write (xcache), directly, on your production linode instance, really shows that you are likely treating your server instances as pets and not as cattle, which doesn't really work in the cloud / server 'farm' paradigm. It also shows that you're likely not working in a large, audited secure environment wherein all commands/actions/configuration changes need to be signed off / logged. I'm also going to guess you do not understand the intricacies of continuous integration/deployment, security, and many other basic aspects/tenets of system administration, and, thus, do not fully grasp why what you did -- manually compiling a .so on a server -- is such a no-no.
If you'd spent even a few minutes researching the traffic that my "hobbyist blog that likely no one reads" gets or actually reading my previous comment (why would I care about XCache on apt, when that was my whole problem to begin with?), you really would seem like less of a troll right now.
Have you ever managed / ran a site in the top 500? Top 400? Top 300? Top 200? Top 100? No? Ok, then, moving on. I have worked on multiple sites in the top 100, as well as on extremely large software projects with thousands of coders and millions and millions of lines of code.
And actually, yes, I looked at your site, your LinkedIn profile, and whatever. You don't know what you're talking about and are not any good at technology. You may think you are, but you're not. For reference, rank 80,000 is "hobbyist." Break the top 5,000, and we'll discuss whether or not you need xcache or HHVM.
Well, everyone knows that any site outside of the top 10 is just a hobbyist site that no one reads. Scoff!
Thankfully, I don't need to discuss with you whether or not I need XCache. More thankfully, I didn't see your poor advice before trying XCache for myself. It makes a dramatic difference in time till first byte on pages that aren't yet in the static cache (and all pages for users who are logged in).
How dare I try to improve performance for the puny couple million people who visit my site each year, even though Ken Shaw doesn't think they deserve it?
Anyway, I find myself asking why in the world I'm still wrestling this pig when I don't enjoy being muddy, and I realized that there really is no good reason. So, I'll leave you to it and let you have the last word about how bad I am at technology, Linux, updating my LinkedIn profile, using apt-get, etc.
> many high quality sites are tested using automated testing suites (through Selenium, or otherwise)
Big sites like Google* and Facebook* work less and less reliable in IE11 (UI glitches, JS errors, CSS position issues). As almost all of their developers use OSX or Linux and most of the tests run on Firefox and Chrome, it's hardly a surprise. I loved IE since version 3 because of its native UI and its responsiveness, but as there will be no IE12 I will move on as well. Well, Microsoft could open up their browser engine "trident-edge" like they do with dotNet vNext.
* Google.com frontpage shows a unformatted sentence on top left corner for ca. 1 seconds, it seems like a JS loading race-condition. Every other week on FB a few minor features like selecting posts privacy groups are broken for a day or two. The React based search is unstable/broken on Android 2.3 as well, before that the mobile web version stayed already completely unchanged from 2010 to 2014. I don't want to blame them, as I guess the majority of users uses their apps and Chrome/Firefox.
60 comments
[ 2.8 ms ] story [ 99.2 ms ] threadAs for sandboxing, I just had a quick look at task manager and it seems to spawn a new process per tab.
now only Safari left to make a similar commitment and shorten the release cycles...
The real culprit behind us still having to support IE8 for some clients is your average enterprise IT department. They'll find ways to lock down updates on any browser. Just as some IT departments have auto updates locked down on Chrome/Firefox already, they'll probably demand a way to do that with Microsoft's browsers too (or find a way to block the updates without Microsoft's support).
Edit: Thing I forgot to add is that an aggressive patch management strategy just so happens to do great things for technical debt.
i'll take that over the inter-windows-release stagnation and long tail legacy support we have to deal with today.
Honestly I think it'll have surpassed Firefox before the beta of Windows 10 finishes.
Edit: It was Office 2000 that enabled this, called "Web Discussions". You had a "Discussion" button in IE[1]. Here's a paper talking about how useful it was: http://research.microsoft.com/en-us/um/redmond/groups/coet/a...
1: https://msdn.microsoft.com/en-us/library/cc751423.aspx
It used the discussion feature of Microsoft Office Server aka SharePoint Portal Server. The history of SharePoint is very complex but interesting:
https://web.archive.org/web/20120419073951/http://blogs.msdn... , https://web.archive.org/web/20080303180618/http://blogs.msdn... , https://web.archive.org/web/20120409232321/http://www.joinin..., http://en.wikipedia.org/wiki/SharePoint , https://web.archive.org/web/20120519235139/http://www.seocon... , http://en.wikipedia.org/wiki/Microsoft_FrontPage
I remember an SP2003 installation with thousands of sub portal sites, hundreds of GB (blobs) stored in SQL server. What I really don't understand is the almost non-existing upgrade paths (between versions '01, '03, '07, '10, '13) and the URL-hell (IIS URL alias would solve that).
Instead of Cairo-OS, WinFS, an improved Explorer shell & improved file server, nowadays SharePoint fulfill various enterprise needs. http://en.wikipedia.org/wiki/Cairo_(operating_system) , http://en.wikipedia.org/wiki/WinFS
I also didn't know how to scale the solution up to allow it to work on every web page for every users.
Also, I anticipated that there would be lots of privacy concerns as you'd basically be collecting every web page a user went to.
This is actually fairly trivial to do right.
2. We also wanted to provide real-time stats for pages, sites, and hosts. This requires IDing the user and page in a reversible way. Even if it's not reversible, you could easily use a rainbow table to reverse, especially with the limited IPv4 namespace.
However, it seems that such URL collection isn't too big of a concern among the general population.
You also have to maintain plugins or extensions across all the major browsers, which is a pain.
This was a project I was working on before completing a CS degree and/or getting exposure to some of the solutions that could be used. I'd be interested in exploring it again, but I have a few more interesting projects on the stack for now.
Additionally, there are many other large databases (Hadoop, etc) that will scale linearly. While it may not be ideal for this use case, but a proper multi-master setup with many read slaves in either PostgreSQL or MySQL could be described as being able to scale linearly to some unspecified extremely large upper limit (see work done previously at Yahoo, Google, Amazon, et al). Much of this also depends on what you define as scaling linearly (are you looking for linear scaling for memory, reads, writes, storage, latency, costs, etc?).
Real time stats for pages, sites, hosts for a shared annotation system across browsers doesn't mesh well with your initial condition of "privacy concerns."
[0] http://techblog.netflix.com/2011/11/benchmarking-cassandra-s...
The "privacy concerns" weren't necessarily my own, I just anticipated that others might have them and therefore not adopt the system. For me, the point was to share what sites you were visiting because you'd be annotating (well, chat/message-boarding) those sites with others. Additionally, I thought it would be cool to see who was where at a given time, what sites were popular, or which pages people found particularly interesting (interesting enough to visit anyway) at any given time.
partition_id = well_distributed_hash(normalize_domain_name(<domain>))
really don't think this would be an issue, or even a concern, as 1 billion writes per second are "Google-levels" of writes. One would likely run out of financial resources supporting an expansion of 86 terrabytes / day (assuming 1kb minimum new data per write), far faster than you would ever max out the capabilities of the technology.
It's more a finance/business exercise to determine if revenue inflows would actually meet, cover, or exceed revenue outflows on a project like this. You can always make the technology scale and meet the demand.
It also sounds like the kind of thing some would want to use to overlay their own advertisements onto other people's websites...
hereby super limited in reality.
and if it's people then you just invented comments. which are toxic most of the time. also invented (rap)genius. congrats, millions of funding for you.
But the font rendering being all blurry is still a showstopper. As is the apparent lack of addons, for blocking (and vim nav).
It's also very unfinished. Alt-D doesn't go to the address bar, which is a pretty big thing to forget... I'm guessing internal users aren't using it.
Also, don't think that somehow just disabling third party cookies is going to make you untrackable or prevent you from being thrown to advertisers.
Also, 3rd party cookie disabling is very difficult to do elsewhere - you can set up a proxy server to filter requests & responses but it has no easy way to determine 1st/3rd party requests.
One of the primary reasons why Microsoft needs to immediately halt, backpedal and release a version that can run on Linux/OSX (beyond the obvious need to port to Android/iOS) is that so many high quality sites are tested using automated testing suites (through Selenium, or otherwise), and those testing instances typically run through bash shells / scripts. While I'm sure you could jury-rig Windows 10 to do that (I've used bash on Windows previously, via Git Bash), you would need to rewrite extensive build and testing tool chains to use non-Unix-y commands --- and even then, you'll likely find many of the open source libraries you rely on are broken, unmaintained, or otherwise unusable on Windows.
As an anecdote, and fairly recently, I actually tried getting unit tests for a pre-existing, fairly sizable project with 10s of developers and many hundreds of thousands of lines of code to run on Windows, and realized it was cheaper to just hand all the developers Mac Books than to either train them on installing Unix tool chains on Windows, or on "properly" using Linux -- especially considering they were not responsible to write the unit tests, just run them. It's also much easier to cross-build for Windows from a Unix system, thus it was possible to completely eliminate Windows in the release process almost completely, other than for later manual testing/verification that can't be automated anyways.
I honestly couldn't care much if they supported Android or iOS. I'm simply pointing out that the competition -- Chrome, Firefox, Opera -- all have these features, and are what people consider "modern." You can't go backwards on featureset and still be considered modern.
Of course, your argument would be that of course Safari on iOS has a large mobile market share, so it qualifies as 'modern', in spite of the fact that it doesn't run on a UNIX system that can be easily scripted.
But are you going to really argue that Windows doesn't represent a significant marketshare of users?
If you're willing to buy all your windows developers macbooks to help them run unit tests, what's to stop you ordering all your UNIX developers a windows laptop to host windows-only browsers running tests driven through a remote webdriver just like the ones that you run on iOS devices?
Did you try Cmder? That gets you a pretty reasonable bash environment on Windows with a single install that's dead simple.
The quickest, fastest way that I know to get the Unix shell commands/stuff up on Windows is to use the packaged Git installation (which I referenced in my previous post), but the issue then is that if you have ever dealt with semi-large code bases that involve one or two separate programming languages, then every developer has to track down all the various packages (if they exist), build them, or otherwise install / get them to work. This is often why in companies Windows devs are just given a shell account on a central Linux server to run their unit tests, or runs them inside a VM on Windows. Windows doesn't have any kind of central package manager akin to apt / yum / port for Unix systems that would allow for easy and quick installation of widely used open source software. While they are trying to push their own package manager on Windows, I don't see that as being successful anytime soon.
And, ultimately this approach (of installing Unix toolchains on Windows) is just a hackish workaround, and doesn't address the root issue that the most powerful automation toolsets in the world are all written / developed on / designed for Unix-like systems, and they simply do not run natively on Windows. If Microsoft genuinely wants to join the modern development ecosystem, they will provide cross platform versions of their browser and keep them synced and up to date across platforms, so that they can be plugged into the existing infrastructure (and thus investment) companies have made in their development environments, automated testing, and continuous integration/deployment.
Microsoft can not ignore (by virtue of exclusion) Linux / OSX (and other Unix-es) if they want wide-spread adoption of this new Spartan browser, simply because they want to push the Windows platform. That strategy may have worked in the late 90s, early 2000s when there was no other options for a readily usable, simple user experience desktop platform , but that's not the case any more.
Most people install a better terminal emulator to replace OS X's default terminal app anyway, so we're all installing something to get a nice experience. I really haven't missed any of my Mac's command line friendliness when on my Windows machines using Cmder.
Chocolatey is a fairly popular apt/yum equivalent on Windows. Most anything built on Node, like npm, bower, or jspm, works fine too.
Could things be better? Sure. Every platform has room for improvement in areas. As a developer primarily using Windows here, my day-to-day experience just doesn't seem anywhere nearly as bleak as you're describing though.
Also, the thing here is that it's not optimal, and there's also non-trivial licensing costs when building large continuous integration/deployment systems. Additionally, I don't believe you would be very supportive of the experience on Windows if you were more familiar with what is possible on Linux, OSX or any other Unix, and if you had strong understanding/knowledge/command of the toolsets available on those ecosystems.
There is nothing fundamentally wrong with using Windows as a regular desktop environment (I'm forced to almost every day). It's actually a fairly good experience (from a desktop perspective), but it doesn't give developers and system admins true, powerful out of the box toolsets. For instance, installing PostgreSQL/MySQL/Apache/Nginx/or whatever on Windows is extremely painful, cumbersome, and not standardized across systems. Conversely, compare this: (yum|apt-get|port) install (postgresql|mysql|apache|nginx).
To do proper automation on large sets of Windows systems, you need Windows Server, Active Directory, and Domains properly setup configured, and licensed, especially if you have any kind of security policy and need to push / control updates from a central server and keep strict control of / standardized versions across systems (for instance, in a strict, actually PCI compliant environment). Why bother with any of that when all of that mess / problem is taken care of by your distribution (OSX/Linux/etc), as one would expect it to be. There's no dependency graphs with large sets of Unix-likes, unlike in the Windows ecosystem -- and that really is the main issue here.
Of course you're right that things like bash aren't present on a fresh install of Windows. I just don't see much issue with needing to run one Cmder install though, because I know almost no one who uses the built-in terminal app on OS X either. Installing your preferred terminal is somewhere around step 2, after installing your preferred browser. At that point, it's a wash.
> Additionally, I don't believe you would be very supportive of the experience on Windows if you were more familiar with what is possible on Linux, OSX or any other Unix, and if you had strong understanding/knowledge/command of the toolsets available on those ecosystems.
That's a huge assumption. Over the years, I've spent a ton of time with everything from DOS 1.0, to the Amiga CLI + REXX, to Solaris and AIX, to Slackware/RedHat/Ubuntu, to OS X, and to Windows. I first learned assembly on SGI Indigos running Irix and first accessed the web via Mosaic running on SPARCstations. I feel fairly confident in my perspective when it comes to the nuances of various platforms, but I currently prefer Windows.
I mean this in the least confrontational way possible, but that's precisely the kind of off puttingly patronizing "you'd understand if you didn't use Windows" shtick I often see from Mac/Linux users that motivates me to comment on these threads.
Heck, just last weekend I was ripping a buggy apt-installed xcache out of the Ubuntu/Linode apache server that hosts my blog and replacing it with a compiled .so to fix a bizarre edge case where xcache was breaking one of my WordPress plugins (and sucked up two weeks, on and off, of debugging with the plugin's author). In my experience, these type of opaque problems are tremendously more common on *nix than on a modern Windows Server.
BTW, I use ssh from the Cmder command line when I log in to that Linode VPS, just like you might from the command line on any other platform.
> For instance, installing PostgreSQL/MySQL/Apache/Nginx/or whatever on Windows is extremely painful, cumbersome, and not standardized across systems. Conversely, compare this: (yum|apt-get|port) install (postgresql|mysql|apache|nginx).
Come on. No one who has ever installed any of those things in production would pretend it's so simple. You're going to spend so much time on configuration that the difference between apt-get and running an .msi is negligible.
Actually, no. This discussion is about development and configuration of a workstation for development and the necessity to have the developers run the same unit tests that also need to run the same on the integration servers (not Windows). For the vast majority of cases, actually yes, all one needs is a apt-get/yum/port install of the package dependencies and that's it -- most if not all "out of the box" configuration for most developers will work just fine for the development environment (ie, the developer's workstation). Additionally, those system package managers provide a much simpler and easier way for a developer to manage system updates (have you ever used Windows update? it's unbelievably slow).
And, to your above reference, re: Ubuntu, while I've personally never had any issues with using Ubuntu as a production server, I wouldn't recommend doing that (and do not use it where I have direct authority/control or choice), because for production one would want 'debian stable' (and is what I have recommended for years). One would not want a headless server environment to use Ubuntu, as the differences that make 'Ubuntu' vs 'debian testing' are primarily downstream additions that are only good/applicable to the desktop and do nothing to help the underlying stability of the system.
To emphasize here, I am not discussing simple one-off Wordpress deployments for your hobbyist blog that likely no one reads, and that you most likely don't even need xcache for. I highly doubt you have the traffic volumes wherein xcache would actually show significant improvement/performance over nothing at all (do you even understand what xcache does?). And if you did, you should likely move on to HHVM (which, btw, is production ready, and works out of the box for the most popular distributions).
Quite frankly, the fact that you are discussing compiling a .so for xcache on Ubuntu shows just how far behind the time you are on the state of Ubuntu and PHP as there are working xcache apt repositories that you can use quite simply, please see: https://www.dotdeb.org/ . Your anecdotal failure of having a problem building a single .so (which you shouldn't have been wasting time compiling yourself anyways), is only representative of your particular issues and is not at all representative of how software is actually used, developed, tested, and deployed in large, significant (monetarily, culturally, politically, etc) systems.
Additionally, the most basic "best practices" for system administration would call for the use of packages wherever possible. Manually compiling extensions (or other dependencies) that you did not write (xcache), directly, on your production linode instance, really shows that you are likely treating your server instances as pets and not as cattle, which doesn't really work in the cloud / server 'farm' paradigm. It also shows that you're likely not working in a large, audited secure environment wherein all commands/actions/configuration changes need to be signed off / logged. I'm also going to guess you do not understand the intricacies of continuous integration/deployment, security, and many other basic aspects/tenets of system administration, and, thus, do not fully grasp why what you did -- manually compiling a .so on a server -- is such a no-no.
Please understand, I am com...
And actually, yes, I looked at your site, your LinkedIn profile, and whatever. You don't know what you're talking about and are not any good at technology. You may think you are, but you're not. For reference, rank 80,000 is "hobbyist." Break the top 5,000, and we'll discuss whether or not you need xcache or HHVM.
Thankfully, I don't need to discuss with you whether or not I need XCache. More thankfully, I didn't see your poor advice before trying XCache for myself. It makes a dramatic difference in time till first byte on pages that aren't yet in the static cache (and all pages for users who are logged in).
How dare I try to improve performance for the puny couple million people who visit my site each year, even though Ken Shaw doesn't think they deserve it?
Anyway, I find myself asking why in the world I'm still wrestling this pig when I don't enjoy being muddy, and I realized that there really is no good reason. So, I'll leave you to it and let you have the last word about how bad I am at technology, Linux, updating my LinkedIn profile, using apt-get, etc.
Cheers.
Big sites like Google* and Facebook* work less and less reliable in IE11 (UI glitches, JS errors, CSS position issues). As almost all of their developers use OSX or Linux and most of the tests run on Firefox and Chrome, it's hardly a surprise. I loved IE since version 3 because of its native UI and its responsiveness, but as there will be no IE12 I will move on as well. Well, Microsoft could open up their browser engine "trident-edge" like they do with dotNet vNext.
* Google.com frontpage shows a unformatted sentence on top left corner for ca. 1 seconds, it seems like a JS loading race-condition. Every other week on FB a few minor features like selecting posts privacy groups are broken for a day or two. The React based search is unstable/broken on Android 2.3 as well, before that the mobile web version stayed already completely unchanged from 2010 to 2014. I don't want to blame them, as I guess the majority of users uses their apps and Chrome/Firefox.