Podcasts about firefox os

We spent time with Desigan Chinniah aka Dees or Cyberdees, a successful technology entrepreneur and investor in under-represented minority founders.  In this episode, we explore his journey through the dotcom era (his time at Mozilla and deprecating Flash), taking risks, building diverse teams, the rise of AI, and much more. This episode is full of insights into succeeding as a technology entrepreneur! From staying curious and staying focused on things that bring joy and energy to exploring new opportunities through taking risks - there is something for everyone! So why not give it a listen? We guarantee you'll learn something valuable about navigating the world! (0:06:03) The Journey of a Technology Entrepreneur: Dees talks about his personal experience of getting into the tech industry, nurturing relationships, and his multicultural family background. (0:14:46) Empathy and Investing: The conversation focuses on topics such as Firefox OS, deprecating Flash from the web, taking risks, building diverse teams, and the rise of AI. Dees encourages listeners to take risks and be empathetic when hiring and managing teams. (0:26:33) Navigating a New World: The speaker discusses the African continent, the future workforce, and the potential for disruption, as well as the importance of time management and creating calendar entries to remind oneself of important tasks. (0:33:46) Staying Focused on What You Want: The conversation concludes with the idea of staying curious and staying focused on the things that bring joy and energy, even when it is hard to achieve. --- Send in a voice message: https://podcasters.spotify.com/pod/show/the-grinders-table/message

À la question, et si Twitter ne faisait plus partie des applications disponibles sur l'App Store d'Apple et le Play Store de Google, Elon Musk a une réponse toute trouvée. Le nouveau patron de Twitter serait tout à fait disposé à construire son propre smartphone pour barrer la route aux deux magasins d'applications les plus populaires, et ainsi continuer à proposer Twitter sur smartphone. Là, on est dans de l'anticipation, certes, mais ça vaut quand même le coup d'œil.Peut-être verra-t-on bientôt la naissance du « tELONphone », un nom inventé par la commentatrice politique américaine conservatrice Liz Wheeler. Dans un sondage sur Twitter, tel un hommage à Elon Musk qui lui aussi adore les sondages Twitter, elle a demandé aux internautes si ces derniers seraient prêts à utiliser le téléphone fabriqué par l'homme le plus riche du monde si ce dernier venait à en lancer la production. Sur plus de 130 000 réponses, 51% des internautes ont répondu que oui, ils seraient prêts à se laisser tenter. De quoi alimenter la réflexion de celui qui est aussi le patron de Tesla et SpaceX. Tout cela intervient dans un contexte assez particulier, seulement quelques jours après que le fondateur et ancien PDG de Twitter, ait pris position en faveur de la création d'un nouveau système d'exploitation mobile, mais qui fonctionnerait uniquement avec du web. On peut notamment se souvenir de l'essai infructueux de Mozilla avec Firefox OS, dont le développement a été abandonné en 2016.Pour l'heure, il n'est pas question que Twitter quitte l'App Store et le Google Play Store. Mais visiblement, Elon Musk ne semble pas insensible à l'idée de lancer son propre mobile avec son propre système d'exploitation. D'ailleurs, Musk serait particulièrement agacé par les 30% de commission de que les géants Américains prélèvent sur tous les achats dans les applications. En prenant en compte le fait qu'Elon Musk prévoit de faire payer le badge de certification bleu au prix de 8 euros par mois, si les internautes effectuent cette transaction sur mobile, Apple prélèvera par exemple 2,40 euros. Si Twitter était banni sur Android et iOS, la version web, quant à elle, subsisterait, mais forcerait un bon nombre d'internautes à modifier leurs habitudes. En résumé, c'est une affaire de gros sous comme toujours qui se joue ici. Fort d'une popularité clivante, certes, mais néanmoins très forte, Musk pourrait se lancer dans la construction d'un nouvel OS et donc d'un « tELONphone » comme baptisé par Liz Wheeler. Reste à savoir si après avoir racheté Twitter pour 44 milliards de dollars, l'homme le plus riche du monde serait prêt à se lancer dans une autre entreprise très coûteuse, où il n'a pour l'instant aucune expérience. Hébergé par Acast. Visitez acast.com/privacy pour plus d'informations.

À la question, et si Twitter ne faisait plus partie des applications disponibles sur l'App Store d'Apple et le Play Store de Google, Elon Musk a une réponse toute trouvée. Le nouveau patron de Twitter serait tout à fait disposé à construire son propre smartphone pour barrer la route aux deux magasins d'applications les plus populaires, et ainsi continuer à proposer Twitter sur smartphone. Là, on est dans de l'anticipation, certes, mais ça vaut quand même le coup d'œil. Peut-être verra-t-on bientôt la naissance du « tELONphone », un nom inventé par la commentatrice politique américaine conservatrice Liz Wheeler. Dans un sondage sur Twitter, tel un hommage à Elon Musk qui lui aussi adore les sondages Twitter, elle a demandé aux internautes si ces derniers seraient prêts à utiliser le téléphone fabriqué par l'homme le plus riche du monde si ce dernier venait à en lancer la production. Sur plus de 130 000 réponses, 51% des internautes ont répondu que oui, ils seraient prêts à se laisser tenter. De quoi alimenter la réflexion de celui qui est aussi le patron de Tesla et SpaceX. Tout cela intervient dans un contexte assez particulier, seulement quelques jours après que le fondateur et ancien PDG de Twitter, ait pris position en faveur de la création d'un nouveau système d'exploitation mobile, mais qui fonctionnerait uniquement avec du web. On peut notamment se souvenir de l'essai infructueux de Mozilla avec Firefox OS, dont le développement a été abandonné en 2016. Pour l'heure, il n'est pas question que Twitter quitte l'App Store et le Google Play Store. Mais visiblement, Elon Musk ne semble pas insensible à l'idée de lancer son propre mobile avec son propre système d'exploitation. D'ailleurs, Musk serait particulièrement agacé par les 30% de commission de que les géants Américains prélèvent sur tous les achats dans les applications. En prenant en compte le fait qu'Elon Musk prévoit de faire payer le badge de certification bleu au prix de 8 euros par mois, si les internautes effectuent cette transaction sur mobile, Apple prélèvera par exemple 2,40 euros. Si Twitter était banni sur Android et iOS, la version web, quant à elle, subsisterait, mais forcerait un bon nombre d'internautes à modifier leurs habitudes. En résumé, c'est une affaire de gros sous comme toujours qui se joue ici. Fort d'une popularité clivante, certes, mais néanmoins très forte, Musk pourrait se lancer dans la construction d'un nouvel OS et donc d'un « tELONphone » comme baptisé par Liz Wheeler. Reste à savoir si après avoir racheté Twitter pour 44 milliards de dollars, l'homme le plus riche du monde serait prêt à se lancer dans une autre entreprise très coûteuse, où il n'a pour l'instant aucune expérience. Learn more about your ad choices. Visit megaphone.fm/adchoices

Live from Breakpoint 2021, Brendan Eich sits down with Anatoly Yakovenko to discuss integrating Solana into the Brave Browser, the huge potential for a decentralized search engine and NFTs as entry point to the metaverse. 00:09 - Intro00:54 - Integrating Solana in Brave08:00 - Challenges with creating the browser09:23 - How to scale crypto to the general public11:57 - A Decentralized search engine14:46 - NFTs as entry point to the metaverse16:35 - Mobile vs. Desktop18:00 - Languages and smart contract development20:40 - How to grow crypto to mass adoption22:44 - Global Peer-to-Peer environment in Crypto Brendan (00:10):Great conference.Anatoly (00:11):I know. Thank you. I'm really excited to be on stage here with you. You're-Brendan (00:15):Same, [crosstalk 00:00:17].Anatoly (00:16):... One of my heroes. As a programmer, JavaScript is a language that really revolutionized how we do application development, how we build. It's the foundation of the web. And I often think of web 3.0 really just being the web, just part of the bigger web.Brendan (00:34):Yeah, me too. That's how the web grows, by evolution. So we think the web 3.0 browser should be the gateway to a billion crypto users. And we are therefore integrating Solana into Brave soon as we can. And here's the cool thing, this is an evolutionary path. We're going to make it so any dapp that is Solana enabled, wherever other chains, EVM compatible or Ethereum, whatever it supports, if it supports Solana as well, we'll make it use Solana by default. So dapp builders who build for Solana as well as other chains. In Brave it's going to use Solana. And that's going to just help, I think, pull all the dapps on the Solana.Anatoly (01:24):Super exciting.Brendan (01:25):You like?Anatoly (01:25):Yeah, it's wonderful. Yeah.Brendan (01:28):Let's see what else. What do we like about Solana? We like NFT games, we like DeFi a lot. We want to make it easy for users to earn and get yield without having to be super expert or do a lot of complex operations. So we're going to work on building that probably in the first half of next year into the wallet so that you can just robo-earn, robo-yield. And we want NFT galleries and NFT transactions to be super slick. I was inspired by the Jules Urbach talk earlier today, and the demo earlier here with NFTs, there were several of them actually, it's all good.Brendan (02:07):We want as many NFT marketplaces integrated as we can, so that's on the agenda. And yeah, [Radium 00:02:13] is there, of course. Radium's still earning, yielding good. The thing that we do now with basic attention token tends to have to settle on Ethereum and it's going to cost you gas. And our valued settlement partners like Gemini, Uphold bitFlyer in Japan, but once we're on Solana, I suspect that BAT, which is already reflected through Wormhole, proxied through Wormhole, might just find it's better to settle on Solana. What do you think?Anatoly (02:41):Yeah, for sure. Absolutely.Brendan (02:44):I'm giving you the softballs here. And we really do want to get this out to all users. We think, whether you're having a hard time in some part of the world where it's hard to get banks to let you save or borrow, or you're beyond banks like a lot of us are or want to be, Solana is the way to do it. And I mentioned auto earn already, got ahead of myself, but I think this is going to be huge. It takes some skill, you got to make sure if you get on the wrong side of yield farming, you go somewhere where the grass is greener, but we'll make it as automatic and easy as possible. And it's just so much better on Solana. I'm making you blush. And yeah, the dapp ecosystem is growing, but if we do this Solana default on multi chain dapps, I think we'll just pull every dapps that's really popular over that Brave users want, and I hope that's going to be every dapp.Brendan (03:37):So here's more NFT marketplaces. There are lots of cool projects in crypto, so we're not doing only Solana, we have obviously Ethereum, we're going to do Bitcoin in the new wallet. It's coming up fast, it's in the Brave nightly builds. And we might do other chains, but I think it's important to pick a chain as default. This is a lesson we learned the hard way with search engines, because when you make a search engine the default, first of all, you can get paid if you get a deal, not always true. And really the user expects to just type keywords into the address bar and search. We want the wallet to have a fast, good default and that's Solana. So enough said. And we're bringing it to mobile too. This is important. I think a lot of fragmentation has occurred due to how wallets are split across mobile and desktop. We're seeing some good mobile first or mobile also wallets. We want to do it mobile and desktop feature parody, evolve at the same time. And we're happy to do that with Solana's partner.Brendan (04:42):So the last bit of news is the BAT system is a triangular system that involves privacy preserving ads. And users opt into it to get 70% of the gross revenue. What we've built so far has a part of our BAT ad system requiring us to verify things, to be the trust third party, which is a security hole. And so we started a project called Themus and worked with several crypto projects to see if we could bring it to high speed chains that can do things, like you need smart contract systems for zero knowledge proofs, you need some part of it in the browser because you're measuring attention. You don't want to put your detailed attention log on any blockchain, however fast, because it'll fingerprint you. So we're using black box accumulators in the browser with Themus and we're then minting ZK proofs. And the cool thing about Solana is we can just put those on-chain, no aggregator, no trusted third party. So we're getting rid of ourselves, we're firing ourselves as a trusted third party. And that's something we're excited about.Anatoly (05:40):And that's awesome. That was, feels like two years of research. It took quite a while to get to that design.Brendan (05:47):And now it's going fast. I think now we've got good working relations with Solana and we can crank out the Rust Co, because we love Rust. Because I was executive sponsor of Rust at Mozilla, so I have a tear in my eye to see my little babies all grown up. And Amazon's hired a bunch of the Rust core team. It's okay, they need jobs. But yeah, we want BAT to be fast, low fee, DeFi base pair and for ads on Solana. So Brave and Solana are doing the new crypto and ad system and it's going to be awesome. Thanks.Anatoly (06:24):That's awesome. I'm a huge fan of the web, huge fan of all the work that you guys have done and Brave. And I remember pre-mobile days, I was working on Brew and I was trying to optimized the web and flip phones. And there was a brief moment where the iPhone came out, we had a browser, and it felt like the web has opened up. And then it just got away from us.Brendan (06:49):That's right. Jobs said when he did the iPhone one, he said, "The web finally works on a phone." And then the story I heard from somebody who would is that they had to port a bunch of games which were C++ or whatever, and they had to do native apps. And they never looked back after that. But I think the web can always catch up and should catch up. And web 3.0, if you have this evolutionary path with dapps and dapp triggers from webpages, then you just evolve into it.Anatoly (07:19):Yeah, that to me is the really exciting part, is there's now an opportunity to have cryptography power the next generation, how web is monetized. Whether it's through advertisement, like with zero knowledge proofs or through direct payments and micro payments. Do you feel like Apple's going to crush us?Brendan (07:41):People a few years ago were worried about this Facebook thing, Libra and now DM. And they got crushed because some politicians hate them. But Apple is very cautious, and if they're doing anything with blockchains, it's a ways out. And then when they arrive in, it's going to be the diva at the party at midnight, like, "Start the party now," and the booze has already run out. So we're going to drink all the booze first.Anatoly (08:06):All right. I'm down for that. What are some of the challenges with building a browser for general consumers, but also with cryptography?Brendan (08:17):This is the problem with browsers is they are universal apps. You spend a lot of your digital life or online life in them. And so if you make the crypto stuff be this expert only area, or it's scary. I use wallet apps, I use ledger hardware wallets, but it's a little bit scary because you feel like, "Did I forget my pin in or did I have to reset it and do the word list?" And there's some anxiety and fear of loss. We want to make crypto be a positive sum, that's why the robo-earn is important to us. Just like with BAT private ads, you could get 70% of the revenue.Brendan (08:53):So you're always building up your assets as well as spending or sending them. And it should be slick, it should be for e-commerce. You can even do things like dis intermediate Amazon. I won't give away all my secrets, but we think we can do that without having a bunch of JavaScript user scripts attack every merchant checkout flow. We think there's a way to get into the interchange charge and do it. And crypto everywhere. It should be slick, should be easy, should be comfortable, make you feel like you're going to win, not lose.Anatoly (09:23):What about custody and keys? How do I get my parents to understand this stuff?Brendan (09:28):Yeah, it's really a little different, but we're looking at Taurus, we're looking at various ideas for backing up your keys that don't just put it on paper and word list in the safe, which we've all been through. And in some ways, the old web went with username and password and had to add a second factor, which often had to be a temporary access number generator on your phone. So at that point you're almost as complex as self custody. I would say you just have this more conventional recovery path. You lose your phone, you know your email, you can try to prove that you're the same person to Coinbase or whatever. But I think self custody has a complimentary role and we want both. We want people to use self custody and be comfortable with it, so we're looking at all these usability challenges. And we think we can get it just almost as good. And then unfortunately the regulators insist, if you want to do Fiat on/off, you're going to go through a custodian.Anatoly (10:20):Of course. The challenges, that's the exciting part. No one has figured this out yet and we're going to dive right in and see, how can we actually scale crypto to the general public?Brendan (10:31):Make it easy for your parents.Anatoly (10:32):Yeah. Yeah, would love to see it. What do you guys see as the tension between the app store on the mobile device and the mobile web?Brendan (10:42):Discoverability is always a problem. And we don't want these brutal curators like Apple. So having lots of stores is good, but then you have the need for a search engine, which Brave now has, which is a private engine and also involve users opting into building the index incrementally, that's the web discovery project. So we're going to aim, because we're very crypto first and our ad sales teams, one of who's here, always looks at crypto options and NFT options, we're going to aim at making our search engine best for crypto. It already uses [inaudible 00:11:14] charting, and it's still in beta, but we're working out all the kinks, so I think search, the good old search we remember from 2004 when Google was great needs to come back and it needs to be the way you find stuff in marketplaces and crypto exchanges.Anatoly (11:29):That's awesome. What kind of information do you think users would want out of a crypto first search engine or curated environment that's different from the traditional web?Brendan (11:39):Search almost gets into, is somebody trying to SEO you and compete for keywords? We're aware of this problem and there's no silver bullet. But we think with crypto, you might actually have a better chance at mechanizing this and having a fair playing field, an automated system for finding the lowest fees and the best yields.Anatoly (11:57):Is there hope for a decentralized search engine?Brendan (12:01):Yeah. So I had a friend who was involved with pre-research, Rich Scrantom, and pre-research looks like it's running a bunch of nodes [inaudible 00:12:07] Google, which Google does not like. And if they're running on [inaudible 00:12:10] IPs, Google's going to shut them down or use their anti-bot team to take them out. We're building a legitimate search engine, but we can't decentralize the algorithm easily because search is sharing queries, looking for some kind of objective best results like page rank, the eigenvalues of the random walk. And decentralizing that is a research problem as far as I know. But we have an active team, we're evolving search and we need your help because we're trying to crowdsource the incremental indexing of the web, we're not trying to index everything from 1998 on. Only Google can do that. Hats off to them, but their time is passing.Anatoly (12:49):When I was growing up as an engineer, the web was just starting, I was really passionate about Linux. And I had this dream of a Microsoft-free personal computer. It feels like the web 3.0 is potentially a dream of ad exchange free, that parasitic Google free web. Is that possible?Brendan (13:13):If you don't collect the data you won't go wrong that way. There's still other ways that central powers can turn on their users and take advantage of them. But I think there is, and that means ultimately you might need hardware that's indie or that's user first. And Brave's not capitalized to do this yet, but I know people, including friends from Firefox OS, which actually after it folded at Mozilla, continued in [inaudible 00:13:37] OS. And there's an open source lineage that you can trace back. And people at Qualcomm, we both know-Anatoly (13:42):Of course, yeah.Brendan (13:42):... We are working on it at the time. So I think there's a chance for a new open source OS that has web 3.0 and none of this Java or swift native stuff. And JavaScript, web 3.0 All the way down.Anatoly (13:55):Are we going to end up building a phone?Brendan (13:57):Brave OS. I don't know, I'd have to raise some more capital.Anatoly (14:03):Yeah. Yeah, that's a way to nerd snipe me for a couple years.Brendan (14:07):But people need independent hardware that serves their interest first. Absolutely.Anatoly (14:10):For sure. It always feels like that's a really tough challenge. But every two it gets easier and easier, hardware gets cheaper and cheaper and the tools get better and better.Brendan (14:19):And then Apple has something new and shiny that the commodity hardware can't match for another year or two, but that's just the nature of the game. So I'm sure we'll have iPhones, but we can probably have BAT phones too. Solana phones.Anatoly (14:33):The BAT phone. I love that. The BAT phone sounds really cool. As you guys see the web 3.0 evolving, I think from your presentation, NFTs were such a huge focus as well. Do you think this is the entry point for the Metaverse as people call it or that really interactive rich environment with ownership of the stuff around you?Brendan (14:56):Yeah. I think you have to keep running at these problems. And usually if you're a startup and the timing isn't right, or something goes wrong, you run out of capital and then the investors reset, or maybe they try again. With crypto, we have this great ability to just keep leveling up. So we're seeing Bitcoin, now we're seeing smart contracts on Ethereum, now we're seeing Solana. And as you level up, you can start to do some of these things that seemed hard before. Like you want some kind of cryptographic proof of ownership.Brendan (15:26):I think one of the demos talked about this. You want to make sure that somebody doesn't copy the pixels. And if you get into VR, there's been interesting research on this. And my friends at [inaudible 00:15:36] have done some work on this. You can actually watermark in a way that's indelible. And if somebody copies your art and tries to remove the watermark, they degrade the quality, because it's been convolved with the luminance and the chrominance. So I have hopes for this being useful in games and connected verses. And to me, that's the Metaverse, it's not going to be something centrally planned at Menlo park by Lieutenant commander data.Anatoly (16:02):I hope not. What I see out of the gaming companies that we talk to is that, especially the ones that are crypto focused, is the one to build browser first games. Everyone that I talked to had this idea that as soon as you open the page, you jump right into the game. There's no sign up, there's no friction, your wallet is your identity. And you're just exactly where you left off.Brendan (16:24):That took a lot of work at Mozilla, by the way. We did [inaudible 00:16:27] JS and that led to web assembly. And you could show games, in the story, you can start playing them and then you just convert. I think it's a great model.Anatoly (16:34):Do you feel like mobile is expressive enough for that? Or is the difference between iOS and Android and desktop is too hard to actually make that work?Brendan (16:45):There's certainly a difference. Even with the latest chip sets, you're just not as fast, you have less bandwidth all around. But games can scale down because the view port's smaller, there's hope that you can use the kind of tricks that we see with the remote rendering, cloud rendering. So I think mobile is the future, but I heard this 12 years ago, people would say around Silicon valley, mobile's the future. And then they would say, "That means there's no desktop." And that is very false. Everybody with a laptop or any big enough screen and a keyboard is still very high value. And that means the economics there don't go away, it just doesn't grow as fast.Anatoly (17:19):That's true. If you look at the growth of the Solana ecosystem, a lot of the users are basically dust up only.Brendan (17:27):Yep.Anatoly (17:27):That to me says that a lot of folks, maybe there was a switch during COVID where we went from being so much immobile to where we're staring at screens again.Brendan (17:36):A bit of that. You go to India and a lot of people are mobile only, but you need both. And I think as mobile gets stronger, you're just going to see more parody, you won't see this need for apps, which is often artificial. It's like holding the browser back, sandbagging Safari a little bit. This is what my friends at Google, or one of them who went to Microsoft, always accuse Apple of, and it's not wrong. You got to give the browser it's due and then it can compete with native better.Anatoly (18:00):Got to ask you about languages.Brendan (18:03):Okay, [inaudible 00:18:04].Anatoly (18:03):How do you see smart contract development in the future as somebody that had incredible depth and understanding how application development happens on the web?Brendan (18:12):Yeah, I think the thing you're seeing with type script, especially with large teams, is more information that you need some kind of proof system or it could be just a warning system, but it's based on model checking. Often it could be based on higher level models than you can express in sound type system, which is something where there's just this timeless world of types that's potentially syntactically checked and prevents bad things from happening at runtime. You need dynamic systems, dynamic code, JavaScript, and the static checkers.Brendan (18:44):And you get the best of both worlds if you have really good ones. So I remember at Mozilla, we were investing in model checkers for C++ because it's memory unsafe. And you could build these higher level checks that knew about security properties you wanted to enforce. And I think this is what you're seeing with smart contracts. I was talking to somebody I met at the hotel bar about this, because it's still a very fruitful area that's had good research in computer science, programming language theory. And it hasn't always been brought to the programming masses like it should. There were companies like [inaudible 00:19:17] Covarity and others like that. The compilers themselves grew the ability to do plugins for static analysis. And now [LOVM 00:19:26] is there.Anatoly (19:27):Do you think that smart contract development needs to have a high level, easy to use language environment? Or can it be driver code?Brendan (19:37):Yeah, exactly. Driver code in the era of C was the worst code in the kernel.Anatoly (19:42):Driver code with Rust is a little bit less frightening.Brendan (19:45):In fact, a friend of mine who was at Microsoft at the time went to Mozilla and has his own startup now, did it at Microsoft, a checker for driver's C code. Which he could skirt the halting problem and kind of statically reason about it and say, "This is garbage driver code, send it back to the vendor." But yeah, I think you don't want to have happy, fun, JavaScript looseness if there's big money at stake. So I think it's important to have the right tools with the right static and dynamic checking.Anatoly (20:13):Do you think smart contract development is strictly financial or are we going to see things that are not financial that you can actually [crosstalk 00:20:21]?Brendan (20:20):You'll see things that are not obviously financial, but they'll turn into reputation in a game or gifting and those tend to matter too. So you still don't want too many dynamic errors.Anatoly (20:32):That's true.Brendan (20:33):So I talked about this in my chapter in coders org, I'm still a fan of static, even if it's unsound semi-static checking.Anatoly (20:40):What do you guys see as like the opportunity for us to grow crypto to a hundred million users, actual signers?Brendan (20:49):Yeah, I'd to get Brave to that scale in a year or two. It depends on everybody here and others. It also, I hate to say it, depends on the nation states of the world not doing something adversarial. But I think given the state of the world, not a great state, but there will always be options to do things with crypto. The internet routes around censorship, and that's true in the web 2.0 And the web 3.0 world. And it's true with blockchains. You still have concerns you have to fork to undo the censorship, but at least you have options. DoAnatoly (21:26):What kind of applications do you envision will actually drive that growth?Brendan (21:30):I think at first it's going to be people using crypto for payments and for DeFi. And some leading edge of that user base will be getting more sophisticated in doing other things. But just having things like gift cards, where we often find that they're useless points, even if we can use them or Congress passed the law to don't expire, we still just don't use them. We should have much more liquidity. We should have liquidity across all kinds of assets. And this is where you start talking about tokenized securities, and can you have primary and secondary liquidity for companies? I think if you're as old me, you all had a tiny piece of some startup that went sideways for 10 years and then sold. And you couldn't trade it easily. And you might have wanted to do that because you might have been squeezed out when it sold. So there's lots of room for blockchains to solve these problems. I think in general, connecting people more directly getting rid of these officious or censorious intermediaries. A lot of room for application.Anatoly (22:29):In this new evolution of the web, I often describe crypto as a fully connected network, as opposed to a social graph, like on Facebook.Brendan (22:40):Yes.Anatoly (22:40):Do you think that's true? Do you think we're going to enter a stage where I am effectively with my cryptographic signatures, I'm in this true global peer to peer environment?Brendan (22:50):I hope so. I showed at web summit last week, I showed the slide with the correct diagram, which is more like a mesh for decentralized, and the incorrect one, which sometimes is called decentralized, which is really distributed, but it's mostly tree structured. Or if it's a graph, it has a dominating spanning tree. That's Google, that's Amazon. So with projects like Helium, with web RTC making it so you can make connections into the endpoints instead of only out. In the old days in the nineties, we could only make TCP connections out from the browser. I think we're heading toward this world. We have to build it iteratively and collaboratively, we have to get around the concrete firewall problems that web RTC mostly got around, it's still a little dodgy. And I think that is the future. I think we should all have Helium nodes if we can. I'm a fan of the project.Anatoly (23:38):That's awesome. The idea of decentralized browsing on an open source phone connected via an open network.Brendan (23:49):Low raw radio.Anatoly (23:50):Yeah, run by the people. Accessing Solana, that would blow my mind.Brendan (23:55):It sounds too good to be true, but I think it could be true, especially if we build it carefully and quickly enough and get it out there and make it usable, which is why I've always wanted to make Brave be about crypto. Even when we started using Bitcoin for our prototype, it was clear once you shield the user by blocking all those trackers, you break all the economics that pays advertising money into the publishers after taking a big slice out for the middlemen like Google. And if you cut that out, how are you going to reconnect it? It's crypto, peer to peer.Anatoly (24:26):All right, let's do it.Brendan (24:28):Awesome.Anatoly (24:28):I'm excited. So thank you, Brendan. Thank you so much for doing here, for working with us.Brendan (24:34):Thanks.

You're probably listening to this on a smartphone. That smartphone probably cost hundreds of dollars, if not well over a thousand. (Looking at you, iPhone Pro Max owners.) For billions of people around the world, those devices are simply not affordable. Feature phones are alive and well, and KaiOS CEO Sebastien Codeville knows the landscape as well as anyone. KaiOS was created in 2015 out of Mozilla's failed Firefox OS project, and has become a hugely popular operating system on super-cheap phones. KaiOS devices cost as little as $17; they typically have smaller screens and lots of physical buttons; they prize durability and days-long battery life over fancy features. And yet the people who use them, use them in entirely familiar ways. They text, they watch videos, they pay for stuff. For people all over the world, KaiOS-powered “smart feature phones” are a first introduction to the internet, and in many cases their users' primary screen experience. Codeville joined the Source Code podcast to discuss KaiOS, the challenges of building an app store and hardware for cheap devices, and why smartphones won't kill feature phones anytime soon. Or maybe ever.For more on the topics in this episode:Sebastien Codeville on TwitterKaiOS2020's most popular KaiOS apps How Reliance Jio became the world's fastest-growing mobile networkHow KaiOS claimed the third-place mobile crownFor all the links and stories, head to Source Code's homepage.

Про що йдеться у цьому випуску: - Що таке PWA? - Історія PWA - FirefoxOS / ChromeOS - Як Goolge, Apple та Firefox впливали на PWA - Стандарти які загальмували PWA - Нові і старі можливості PWA - Background Tasks / Offline / Web Assembly / FS API Посилання - web.dev pwa: https://web.dev/what-are-pwas/ - Apple Podcasts.app as PWA: https://web.dev/app-like-pwas/ - Apple Payment API: https://developer.apple.com/documentation/apple_pay_on_the_web/apple_pay_js_api) - ChromeOS: https://www.google.com/chromebook/chrome-os/ - FirefoxOS: https://en.wikipedia.org/wiki/Firefox_OS - SailfishOS яку викупили :( :https://sailfishos.org - Тулза для заміток RoamResearch: https://roamresearch.com

Guest Stormy Peters Panelists Eric Berry | Justin Dorfman | Richard Littauer Show Notes Hello and welcome to Sustain! Our amazing guest today is Stormy Peters, Director of the Open Source Programs Office at Microsoft and long-time advocate of free and open source software. Stormy tells us how she started her journey into open source and how she got involved with the OSPO at Microsoft. We find out about the impact of Duane O’Brien’s FOSS Fund, what Stormy is doing at Microsoft to help other nonfinancial ways of supporting communities and building great open source ecosystems of communities, and about how they support Outreachy. Also, Stormy fills us in on where she thinks open source is going in the future, her team’s goals, and their focus on cultural change. Download this episode now to find out much more! [00:01:16] We find out how Stormy got into open source. [00:02:40] Stormy tells us how she got involved with the Open Source Program Office at Microsoft, if she ever found herself defending open source more so than today, and if she ever thought Microsoft would be in a position they are now of how much they’ve given back to open source. [00:04:14] Richard is curious how Stormy feels about sustain, how the process has been like for her, how has it been to see the change from just being a licensing issue to being a culture, and if she thinks most people are paid for open source. [00:08:45] Eric wonders what the overall mentality was for Stormy when she got to Microsoft regarding supporting open source and if it’s changed since she’s been there. [00:12:17] Eric asks Stormy if in five years our whole development environment is on Microsoft platform if we’re going to get locked in and is that going to cause the same type of negative frustration as he is with Apple right now. [00:13:40] Richard wonders if tools are owned by Microsoft how will that affect his development and how will affect the open source ecosystem if very large corporations become the main stakeholders in open source and direct the projects in their own ways, and Stormy replies and also explains how the people get paid. [00:16:10] Justin wonders how much impact Duane O’Brien’s program FOSS Fund has made in the way they operate and the rest of the bigger OSPO’s out there. We also learn what she’s doing at Microsoft to help other nonfinancial ways of supporting communities and building great open source ecosystems of communities. [00:18:53] Stormy fills us in on who makes up their team of employees at OSPO Microsoft and where you can go to see what they are doing. [00:20:12] Richard is curious where Stormy sees the role for OSPO’s for universities, governments, cities, and anything that’s not a large corporation. She also tells us about how they support Outreachy. [00:23:08] We learn from Stormy where she thinks open source is going in the future and why she thinks a Copyleft is dropped out of the parlance. [00:25:49] Stormy tells us how she sees Ethical Source progressing and if she sees it being a major player with people or as being a movement that will cause the same tensions that GPL used to cause. [00:27:24] Richard wonders if Microsoft has a mapping of what resources they have used of what code is in their system, what open source packages they depend on, and how they are actively working towards giving back to them as a whole down the stack. [00:29:12] Eric asks Stormy what is on the forefront of her team’s mind right now, and she fills us in on her team’s goals. [00:29:56] Find out where you can follow Stormy on the internet. Quotes [00:01:53] “And this was just about the time that Linux was getting popular and they had not one, but two desktops that were popular, GNOME and KDE, and I thought surely we can collaborate on this like they do.” [00:03:42] “I’d like to joke now that I think Microsoft’s first contribution to open source was being the common enemy.” [00:04:54] “I think it’s still evolving, and I think it always will evolve and so I think it’s important that all of us continue to think about it and figure out what the new models look like.” [00:05:32] “I think a much larger majority than before get paid to work on open source.” [00:06:33] “So, I know when I was at Mozilla we consciously thought about this with Firefox OS, having people full-time on it and even more than full-time, as they worked extra hours to try to get out the door, could you still welcome people that only had two or three hours a week to work on it.” [00:08:56] “So to go back to the question about my career that it looked like it changed with this last move, I don’t think it did. To me, this was the next step in the path.” [00:09:27] “Microsoft, I think, is ideally positioned to make the next big change in open source software.” [00:12:33] “So it’s my job, extended team’s job, to make sure that Microsoft does open source well, and part of us being successful in open source is making sure we have active communities around our projects that are broader than us so that the projects are broader than us that we’re not creating that lock-in.” [00:14:51] “Microsoft uses a program called FOSS Fund that Duane O’Brien at INDEED started, where we let employees pick a project every month to give them $10,000, and the idea’s that’s not going to be enough money to support them forever but we just want to recognize some of the projects that we’re using that aren’t getting a lot of funding in other ways.” [00:15:54] “Those companies started doing contract work for an open source software project and now they work on open source software projects and other projects in general.” [00:16:34] “I think Duane’s a good thinker, like when COVID started, he started an effort to raise money for the events that were impacted, so I hope that’s empowering to a lot of people that one person can have a good idea that is a need and get people involved.” [00:17:44] “So, we’re unofficially giving Azure Credits to a number of open source software projects. I’m trying to launch an official program by which people can apply to get Azure Credits whether it’s just do their builds or whether it’s to make sure that stuff runs on Azure.” [00:18:05] “We have a lot of Microsoft employees who work on projects on GitHub. I think it’s definitely over 30,000 Microsoft employees have linked their Microsoft identity to their GitHub identity.” [00:23:13] “I think if you’d asked me that like twenty years ago, I would not have realized that Copyleft would drop out of importance as much as it has.” [00:23:36] “I don’t know if I would make an accurate prediction, but I hope it’s to continue to make, not only to make more software available to more people, but to make it more possible for people that aren’t in tech careers to write code and make computers do what they need them to do.” [00:24:20] “I think it’s cause the fear has dropped out. In the beginning it was fear that I was going to have to open source something I didn’t want to and fear that somebody was going to take my stuff and take advantage of my stuff.” [00:29:17] “Our goal is to make sure that Microsoft business units can use open source software in their strategy, that they can consume open source, that they can open source things, and that they have all the tools and knowledge they need to do that.” Spotlight [00:30:41] Eric’s spotlight is Kombucha (KeVita). [00:31:29] Justin’s spotlight is Jekyll Admin. [00:32:04] Richard’s spotlight is Carl Boettiger. [00:33:04] Stormy’s spotlight is Educational Software Projects like Khan Academy and Internet-in-a-Box. Links Stormy Peters Twitter (https://twitter.com/storming) Stormy Peters Linkedin (https://www.linkedin.com/in/stormy/) Microsoft Open Source (https://opensource.microsoft.com/) Microsoft Open Source Blog (https://cloudblogs.microsoft.com/opensource/) FOSS Contributor Fund- Duane O’Brien blog post (https://engineering.indeedblog.com/blog/2019/07/foss-fund-six-months-in/) What is copyleft? By Ben Cotton (https://opensource.com/resources/what-is-copyleft) Outreachy (https://www.outreachy.org/) KeVita Kombucha (https://www.kevita.com/) Open Collective (https://opencollective.com/) Carl Boettiger (https://ourenvironment.berkeley.edu/people/carl-boettiger) Internet-in-a-Box (http://internet-in-a-box.org/) Khan Academy (https://www.khanacademy.org/) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr at Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Stormy Peters.

Developer Advocacy meets VSCode meets MS-Edge. Mit unserem Gast Christian Heilmann sprechen wir darüber, wie es ist, für große Firmen auf noch größerer Welttournee zu sein und wie Microsoft derzeit daran arbeitet, VSCode mit Edge zu einem noch besseren Entwicklererlebnis zu machen. Nebenbei streifen wir noch CSS color-contrast() und warum FirefoxOS vielleicht gar keine so schlechte Idee war. Ein Spaß für die ganze Familie!

In this Podcast, Paul not only shares his experiences at Firefox and launching the Firefox OS, he also gives us a peak into how the way we share our identity online and in the real world is about to change dramatically.

Jeff Beatty is the Head of Localization at Mozilla, an open-source software company headquartered in Silicon Valley. Since its founding in 1998, Mozilla's mission has been to keep the internet open and accessible to all. To that end, Mozilla has harnessed the power of online communities to develop, spread and support its free software to users around the world. Some of its best-known products include the Firefox web browser, the Thunderbird e-mail client, and the Firefox OS mobile operating system, among many others. Jeff is a world-class expert in community-driven translation and localization models. He also specializes in localization pedagogy, translation for under-resourced languages, translation technology and process development, virtual team management, as well as cross-functional and cross-cultural management. Based in Provo, Utah, Jeff has traveled to 31 countries, and speaks three different languages. In addition to his role at Mozilla, he also teaches courses on Computer-Assisted Translation (CAT) at Brigham Young University. He has written articles for trade publications such as Multilingual Magazine, he has been quoted by major media outlets, and he has been a speaker at industry conferences such as LocWorld, GALA, and OpenWest.   Links: Mozilla website Mozilla on LinkedIn Mozilla on Instagram Mozilla on Twitter Lingoport website Middlebury Institute of International Studies (MIIS) at Monterey website BYU Center for Language Studies website Jeff on LinkedIn Jeff on Twitter  

Welcome to the History of Computing Podcast, where we explore the history of information technology. Because by understanding the past, we're able to be prepared for the innovations of the future! Today we're going to look at the emergence of the web through the lens of Netscape, the browser that pushed everything forward into the mainstream. The Netscape story starts back at the University of Illinois, Champaign-Urbana where the National Center for Supercomputing Applications (or NCSA) inspired Marc Andreessen and Eric Bina to write Mosaic, which was originally called xmosaic and built for X11 or the X Window System. In 1992 there were only 26 websites in the world. But that was up from the 1 that Internet pioneer Tim Berners-Lee built at info.cern.ch in 1991. The internet had really only been born a few years earlier in 1989. But funded by the Gore Bill, Andreessen and a team of developers released the Alpha version of the NCSA Mosaic browser in 1993 and ported it to Windows, Mac, and of course the Amiga. At this point there were about 130 websites. Version two of Mosaic came later that year and then the National Science Foundation picked up the tab to maintain Mosaic from 94 to 97. James Clark, a co-founder of Silicon Graphics and a legend in Silicon Valley, took notice. He recruited some of the Mosaic team, led by Marc Andreessen, to start Mosaic Communications Corporation, which released Netscape Navigator in 1994, the same year Andreessen graduated from college. By then there were over 2,700 websites, and a lot of other people were taking notice after 2 four digit growth years. Yahoo! and EXCITE were released in 1994 and enjoyed an explosion in popularity, entering a field with 25 million people accessing such a small number of sites. Justin Hall was posting personal stuff on links.net, one of the earliest forms of what we now call blogging. Someone else couldn't help but notice: Bill Gates from Microsoft. He considered cross-platform web pages and the commoditization of the operating system to be a huge problem for his maturing startup called Microsoft, and famously sent The Internet Tidal Wave memo to his direct reports, laying out a vision for how Microsoft would respond to this thread. We got Netscape for free at the University, but I remember when I went to the professional world we had to pay for it. The look and feel of Navigator then can still be seen in modern browsers today. There was an address bar, a customizable home page, a status bar, and you could write little javascripts to do cutesy things like have a message scroll here and there or have blinked things. 1995 also brought us HTML frames, fonts on pages, the ability to change the background color, the ability to embed various forms of media, and image maps. Building sites back then was a breeze. And with an 80% market share for browsers, testing was simple: just open Netscape and view your page! Netscape was a press darling. They had insane fans that loved them. And while they hadn't made money yet, they did something that a lot of companies do now, but few did then: they went IPO early and raked in $600 million in their first day, turning Marc Andreessen the poster child into an overnight sensation. They even started to say that the PC would live on the web - and it would do so using Netscape. Andreessen then committed the cardinal sin that put many in tech out of a job: he went after Microsoft claiming they'd reduce Microsoft to a set of “poorly debugged device drivers.” Microsoft finally responded. They had a meeting with Netscape and offered to acquire the company or they would put them out of business. Netscape lawyered up, claiming Microsoft offered to split the market up where they owned Windows and left the rest to Netscape. Internet Explorer 1 was released by Microsoft in 1995 - a fork of Mosaic which had been indirectly licensed from the code Andreessen had written while still working with the NCSA in college. And so began the “Browser Wars” with Netscape 2 being released and Internet Explorer 2, the same year. 1995 saw the web shoot up to over 23,000 sites. Netscape 2 added Netscape Mail, an email program with about as simple a name as Microsoft Mail, which had been in Windows since 1991. In 1995, Brendan Eich, a developer at Netscape wrote SpiderMonkey, the original JavaScript engine, a language many web apps still use today (just look for the .jsp extension). I was managing labs at the University of Georgia at the time and remember the fast pace that we were upgrading these browsers. NCSA telnet hadn't been updated in years but it had never been as cool as this Netscape thing. Geocities popped up and I can still remember my first time building a website there and accessing incredible amounts of content being built - and maybe even learning a thing or two while dinking around in those neighborhoods. 1995 had been a huge and eventful year, with nearly 45 million people now “on the web.” Amazon, early search engine Altavista, LYCOS, and eBay launching as well. The search engine space sure was heating up… Then came 1996. Things got fun. Point releases of browsers came monthly. New features dropped with each release. Plugins for Internet Explorer leveraged API hooks into the Windows operating system that made pages only work on IE. Those of us working on pages had to update for both, and test for both. By the end of 1996 there were over a quarter million web pages and over 77 million people were using the web. Apple, The New York Times, Dell.com appeared on the web, but 41 percent of people checked AOL regularly and other popular sites would be from ISPs for years to come. Finally, after a lot of talk and a lot of point releases, Netscape 3 was released in 1997. Javascript got a rev, a lot of styling elements some still use today like tables and frames came out and forms could be filled out automatically. There was also a gold version of Netscape 3 that allowed editing pages. But Dreamweaver gave us a nice WYSIWIG to build web pages that was far more feature rich. Netscape got buggier, they bit on more and more thus spreading developers thing. They just couldn't keep up. And Internet Explorer was made free in Windows as of IE 3, and had become equal to Netscape. It had a lot of plugins for Windows that made it work better on that platform, for better or worse. The Browser Wars ended when Netscape decided to open source their code in 1998, creating the Mozilla project by open sourcing the Netscape Browser Suite source code. This led to Waterfox, Pale Moon, SeaMonkey, Ice Weasel, Ice Cat, Wyzo, and of course, Tor Browser, Swiftfox, Swift Weasel, Timberwolf, TenFourFox, Comodo IceDragon, CometBird, Basilisk, Cliqz, AT&T Pogo, IceCat, and Flock. But most importantly, Mozilla released Firefox themselves, which still maintains between 8 and 10 percent marketshare for browser usage according to who you ask. Of course, ultimately everyone lost the browser wars now that Chrome owns a 67% market share! Netscape was sold to AOL in 1999 for $4.2 billion, the first year they dropped out of the website popularity contest called the top 10. At this point, Microsoft controlled the market with an 80% market share. That was the first year Amazon showed up on the top list of websites. The Netscape problems continued. AOL released Netscape 6 in 2000, which was buggy and I remember a concerted effort at the time to start removing Netscape from computers. In 2003, after being acquired by Time Warner, AOL finally killed off Netscape. This was the same year Apple released Safari. They released 7.2 in 2004 after outsourcing some of the development. Netscape 9, a port of Firefox, was released in 2007. The next year Google Chrome was released. Today, Mozilla is a half-billion dollar a year not-for profit. They ship the Firefox browser, the Firefox OS mobile OS, the online file sharing service Firefox Send, the Bugzilla bug tracking tool, the Rust programming language, the Thunderbird email client, and other tools like SpiderMonkey, which is still the javascript engine embedded into Firefox and Thunderbird. If the later stage of Netscape's code in the form of the open source Mozilla projects appeal to you, consider becoming a Mozilla Rep. You can help contribute, promote, document, and build the community with other passionate and knowledgeable humans that are on the forefront of pushing the web into new and beautiful places. For more on that, go to reps.mozilla.org. Andreessen went on to build Opsware with Ben Horowitz (who's not a bad author) and others. He sold the hosting business and in 2005 continued on with Horowitz founded Andreessen Horowitz which were early investors of Facebook, Foursquare, GitHub, Groupon, LinkedIn, Pinterest, Twitter, Jawbone, Zynga, Skype, and many, many others. He didn't win the browser wars, but he has been at the center of helping to shape the Internet as we know it today, and due to the open sourcing of the source code many other browsers popped up. The advent of the cloud has also validated many of his early arguments about the web making computer operating systems more of a commodity. Anyone who's used Office 365 online or Google apps can back that up. Ultimately, the story of Netscape could be looked at as yet another “Bill Gates screwed us” story. But I'm not sure that does it justice. Netscape did as much to shape the Internet in those early days as anything else. Many of those early contributions, like the open nature of the Internet, various languages and techniques, and of course the code in the form of Mozilla, live on today. There were other browsers, and the Internet might have grown to what it is today. But we might not have had as much of the velocity without Andreessen and Netscape and specifically the heated competition that led to so much innovation in such a short period of time - so we certainly owe them our gratitude that we've come as far as we have. And I owe you my gratitude. Thank you so very much for tuning into another episode of the History of Computing Podcast. We're lucky to have you. Have a great day!

Francisco Picolini, Tech Community & Content Manager at Codemotion (https://codemotionworld.com) , shares his story and tips about working with both technical and non-technical communities. Show links: - Codemotion Communities (https://about.codemotion.com/communities/) - The Story of Firefox OS (https://medium.com/@bfrancis/the-story-of-firefox-os-cb5bf796e8fb)

Firefox has a new speed trick, openSUSE Leap has a time-traveling kernel while the project plans for the future, and we react to Antergros coming to an end. Plus the ghost of Firefox OS lives on in the well-financed KaiOS, GitHub launches sponsors, and obvious uses for the new Google Glass 2.

Firefox has a new speed trick, openSUSE Leap has a time-traveling kernel while the project plans for the future, and we react to Antergros coming to an end. Plus the ghost of Firefox OS lives on in the well-financed KaiOS, GitHub launches sponsors, and obvious uses for the new Google Glass 2.

Firefox has a new speed trick, openSUSE Leap has a time-traveling kernel while the project plans for the future, and we react to Antergros coming to an end. Plus the ghost of Firefox OS lives on in the well-financed KaiOS, GitHub launches sponsors, and obvious uses for the new Google Glass 2.

TechCentral — In this episode of the podcast, Duncan McLeod is joined by Jolla CEO Sami Pienimäki to talk about the implications for the world of smartphone operating systems of the US government’s decision to force Google to hang up on Huawei. In the podcast, Pienimäki discusses the impact the decision could have on Jolla’s Sailfish OS, an open-source smartphone operating system tailored for business users and governments around the world. Jolla, Pienimäki says, has received enormous interest from Chinese smartphone makers in Sailfish OS in the wake of the US government’s directive to Google. Could Sailfish OS, which has its origins in the Linux-based MeeGo OS – previously developed by Finland’s Nokia and US chip giant Intel – potentially be an alternative operating system to Android for Chinese device makers that fear being cut off by Google? Pienimäki explains why he thinks this is the case. Sailfish OS, which runs Android apps, can be installed by users on a range of handsets, with the software actively being developed and ported by a large community of open-source developers. Pienimäki explains why Jolla pivoted from the consumer market – at one time it developed its own smartphone and tablet devices – and into the corporate and public sector markets, and why he believes the US government’s moves against Huawei will shake the foundations of the mobile industry. He talks about Android’s dominance – it’s installed on about 90% of active smartphones – and whether this dominance is poised to be broken by the developments around Huawei. Could a third major smartphone operating system platform now emerge? He provides his views on Huawei’s new Hongmeng OS, and its chances of success, and talks about why he thinks previous attempts to tackle Android’s dominance with projects such as Ubuntu Touch and the Firefox OS failed. It’s a great discussion. Don’t miss it!

Stephanie and Brian rant for a half hour? The world according to DARPA in 2045? Also, Firefox OS, AirBnB, a relationship question, and much, much more... Special Guest: Dr. Stephanie Murphy (Twitter: @S_Murphy_Phd) Stories of the Week:--Random Access: AirBnB cameras, Firefox OS isn’t dead. Hacksec:--“DARPA 2045” Link: read.bi/1NPrOB1 Important Messages:--”Purism computers and the Libreboot? Cloud storage (owncloud) (mention that external kits allow you to update connection type like USB-C)? Would you talk about MaidSafe farming? Self-defense tips? Another relationship question?“ First Choice:--“Qwertycard” Link: www.qwertycards.com/ The Climax:--"Oak Island" Link: bit.ly/1Zf941N APPENDIX:--"LibertyMemes.com" Link: libertymemes.com--”Libreboot X200” Link: bit.ly/1FI57ew--”Complete Liberty: Inside and Out” Link: amzn.to/1IRm5Jg--”The Open Wireless Movment” Link: openwireless.org--”MaidSafe” Link: maidsafe.net--”Markets Not Capitalism” Link: c4ss.org/content/12802 --”Purism” Link: puri.sm--------------------------------------------------------------------------------------------------- Make easy monthly donations through Patreon: patreon.com/sovryntechAnd you can tip me at: sovryntech.tip.me--------------------------------------------------------------------------------------------------- NXT: NXT-4V3J-VA4W-4EY3-GUWV2 NAMECOIN: NHfN1kpj8G9aUCCHuummBKa8mPvppN1UFaLITECOIN: LLUXwfWrKDpuK38ZnPD14K6zc6rUaRgo9WBITCOIN: 1AEiTkWiF8x6yjQbbhoU89vHHMrkzQ7o8d --------------------------------------------------------------------------------------------------- Don’t forget you can e-mail the show at: brian@zomiaofflinegames.comI’m also on Telegram: @SovrynFollow content updates on Telegram: @DarkAndroidBitMessage: BM-NBMFb4W42CqTaonxApmUji1KNbkSESki ---------------------------------------------------------------------------------------------------You can also visit our IRC channel on Freenode: #SovrynBalnea ---------------------------------------------------------------------------------------------------sovryntech.comtwitter.com/sovryntechplus.google.com/+BrianSovryn1i/liberty.me/members/briansovryn/facebook.com/BrianSovryninstagram.com/Bsovryn/steamcommunity.com/id/ninjaprogram/

Stephanie and Brian rant for a half hour? The world according to DARPA in 2045? Also, Firefox OS, AirBnB, a relationship question, and much, much more... Special Guest: Dr. Stephanie Murphy (Twitter: @S_Murphy_Phd) Stories of the Week:--Random Access: AirBnB cameras, Firefox OS isn’t dead. Hacksec:--“DARPA 2045” Link: read.bi/1NPrOB1 Important Messages:--”Purism computers and the Libreboot? Cloud storage (owncloud) (mention that external kits allow you to update connection type like USB-C)? Would you talk about MaidSafe farming? Self-defense tips? Another relationship question?“ First Choice:--“Qwertycard” Link: www.qwertycards.com/ The Climax:--"Oak Island" Link: bit.ly/1Zf941N APPENDIX:--"LibertyMemes.com" Link: libertymemes.com--”Libreboot X200” Link: bit.ly/1FI57ew--”Complete Liberty: Inside and Out” Link: amzn.to/1IRm5Jg--”The Open Wireless Movment” Link: openwireless.org--”MaidSafe” Link: maidsafe.net--”Markets Not Capitalism” Link: c4ss.org/content/12802 --”Purism” Link: puri.sm--------------------------------------------------------------------------------------------------- Make easy monthly donations through Patreon: patreon.com/sovryntechAnd you can tip me at: sovryntech.tip.me--------------------------------------------------------------------------------------------------- NXT: NXT-4V3J-VA4W-4EY3-GUWV2 NAMECOIN: NHfN1kpj8G9aUCCHuummBKa8mPvppN1UFaLITECOIN: LLUXwfWrKDpuK38ZnPD14K6zc6rUaRgo9WBITCOIN: 1AEiTkWiF8x6yjQbbhoU89vHHMrkzQ7o8d --------------------------------------------------------------------------------------------------- Don’t forget you can e-mail the show at: brian@zomiaofflinegames.comI’m also on Telegram: @SovrynFollow content updates on Telegram: @DarkAndroidBitMessage: BM-NBMFb4W42CqTaonxApmUji1KNbkSESki ---------------------------------------------------------------------------------------------------You can also visit our IRC channel on Freenode: #SovrynBalnea ---------------------------------------------------------------------------------------------------sovryntech.comtwitter.com/sovryntechplus.google.com/+BrianSovryn1i/liberty.me/members/briansovryn/facebook.com/BrianSovryninstagram.com/Bsovryn/steamcommunity.com/id/ninjaprogram/

Mobile Operating Systems? Martin Luther King on technology? Also, more thoughts Satya Nadella and OneDrive, #SoftwareMinimalism, , and much, much more… Special Guest: None Stories of the Week:--Random Access: I'll be on Crypto Convos and Declare Your Independence this week, Supercookies, Samsung possibly buying BlackBerry for 7.5 billion, Google may be buying Softcard, Space X is working on launching satellite Internet, US Government claims they've been "hacking" North Korea since 2010 and that's how they know that North Korea hacked Sony Pictures, Facebook for Work and Facebook getting rid of “hoaxes” via algorithm.--”FirefoxOS, Tizen, BlackBerry, and Ubuntu Phone” Tech Roulette:--“MLK on Tech” Link: goo.gl/AtA6d4 Important Messages:--”Satya Nadella? Do you trust OneDrive? How to handle bad actors?”(Use OneDrive due to software minimalism. Windows is still used by 90% of people on the planet and pushing System D onto Windows is a win. Consider ReactOS and Windows 7 Dark.) Tool of the Week:--”The Right Software, or the Software That's Already There?” Hacksec:--”Police Radars Can See In Your Home” Like: goo.gl/92u0Q0 The Climax:--”The Statue of Many Metals” APPENDIX:--”Crypto Convos” Link: goo.gl/EE9bs8--”Declaration Your Independence” Link: www.freedomsphoenix.com/Program-Page.htm--”OneDrive Concerns, Part I” Link: goo.gl/tUzZx6--”OneDrive Concerns, Part II” Link: goo.gl/Hz6g56 ---------------------------------------------------------------------------------------------------You can tip me at: sovryntech.tip.me---------------------------------------------------------------------------------------------------NXT: NXT-4V3J-VA4W-4EY3-GUWV2NAMECOIN: NHfN1kpj8G9aUCCHuummBKa8mPvppN1UFaLITECOIN: LLUXwfWrKDpuK38ZnPD14K6zc6rUaRgo9WBITCOIN: 1AEiTkWiF8x6yjQbbhoU89vHHMrkzQ7o8d---------------------------------------------------------------------------------------------------Don’t forget you can e-mail the show at: brian@zomiaofflinegames.com---------------------------------------------------------------------------------------------------You can also visit our IRC channel on Freenode: #SovrynBalnea---------------------------------------------------------------------------------------------------You can also contact the show through BitMessage at the address: BM-NBMFb4W42CqTaonxApmUji1KNbkSESki---------------------------------------------------------------------------------------------------www.sovryntech.comwww.twitter.com/sovryntechplus.google.com/+BrianSovryn1i/liberty.me/members/briansovryn/www.facebook.com/BrianSovryn

We sift Mobile World Congress to find just the best and most relevant stories, and discuss the Thunderclap vulnerability. Plus we say goodbye to Koroa, find a reason to checkout GRUB nightlies, and how Android aims to kill passwords for good.

Mobile Operating Systems? Martin Luther King on technology? Also, more thoughts Satya Nadella and OneDrive, #SoftwareMinimalism, , and much, much more… Special Guest: None Stories of the Week:--Random Access: I'll be on Crypto Convos and Declare Your Independence this week, Supercookies, Samsung possibly buying BlackBerry for 7.5 billion, Google may be buying Softcard, Space X is working on launching satellite Internet, US Government claims they've been "hacking" North Korea since 2010 and that's how they know that North Korea hacked Sony Pictures, Facebook for Work and Facebook getting rid of “hoaxes” via algorithm.--”FirefoxOS, Tizen, BlackBerry, and Ubuntu Phone” Tech Roulette:--“MLK on Tech” Link: goo.gl/AtA6d4 Important Messages:--”Satya Nadella? Do you trust OneDrive? How to handle bad actors?”(Use OneDrive due to software minimalism. Windows is still used by 90% of people on the planet and pushing System D onto Windows is a win. Consider ReactOS and Windows 7 Dark.) Tool of the Week:--”The Right Software, or the Software That's Already There?” Hacksec:--”Police Radars Can See In Your Home” Like: goo.gl/92u0Q0 The Climax:--”The Statue of Many Metals” APPENDIX:--”Crypto Convos” Link: goo.gl/EE9bs8--”Declaration Your Independence” Link: www.freedomsphoenix.com/Program-Page.htm--”OneDrive Concerns, Part I” Link: goo.gl/tUzZx6--”OneDrive Concerns, Part II” Link: goo.gl/Hz6g56 ---------------------------------------------------------------------------------------------------You can tip me at: sovryntech.tip.me---------------------------------------------------------------------------------------------------NXT: NXT-4V3J-VA4W-4EY3-GUWV2NAMECOIN: NHfN1kpj8G9aUCCHuummBKa8mPvppN1UFaLITECOIN: LLUXwfWrKDpuK38ZnPD14K6zc6rUaRgo9WBITCOIN: 1AEiTkWiF8x6yjQbbhoU89vHHMrkzQ7o8d---------------------------------------------------------------------------------------------------Don’t forget you can e-mail the show at: brian@zomiaofflinegames.com---------------------------------------------------------------------------------------------------You can also visit our IRC channel on Freenode: #SovrynBalnea---------------------------------------------------------------------------------------------------You can also contact the show through BitMessage at the address: BM-NBMFb4W42CqTaonxApmUji1KNbkSESki---------------------------------------------------------------------------------------------------www.sovryntech.comwww.twitter.com/sovryntechplus.google.com/+BrianSovryn1i/liberty.me/members/briansovryn/www.facebook.com/BrianSovryn

We sift Mobile World Congress to find just the best and most relevant stories, and discuss the Thunderclap vulnerability. Plus we say goodbye to Koroa, find a reason to checkout GRUB nightlies, and how Android aims to kill passwords for good.

We sift Mobile World Congress to find just the best and most relevant stories, and discuss the Thunderclap vulnerability. Plus we say goodbye to Koroa, find a reason to checkout GRUB nightlies, and how Android aims to kill passwords for good.

It’s almost Christmas so it’s time to look back at 2018 and talk about some of the news stories that shaped the year.   January Meltdown and Spectre   February Nintendo Switch runs Linux Plasma running on a Switch   March New Raspberry Pi 3B+ The final nail in the Firefox OS coffin   April... Read More

It’s almost Christmas so it’s time to look back at 2018 and talk about some of the news stories that shaped the year.   January Meltdown and Spectre   February Nintendo Switch runs Linux Plasma running on a Switch   March New Raspberry Pi 3B+ The final nail in the Firefox OS coffin   April... Read More

Disclaimer Please note that this podcast may contain swearing or mature references and should be listened to by adults or people with mature supervision. Discussion 18.04.1 and things based off it (or are going to be), Linux Mint 19, Elementary OS, KDE Neon, Zorin OS Gnome 3 and Ubuntu switching to it, stock gnome 3 vs "Ubuntufied Gnome 3 shell" KDE 5 and KDE Neon, design and system resources, LXQT as a "lightweight" desktop environment We briefly talk about Nvidia and AMD cards and drivers and what to buy and what's most compatible Microsoft's Windows as a service, buying a computer without Windows. Rejecting the Windows license, custom built PCs, System 76 and Entroware Should we always attempt to own/jailbreak/reinstall everything? While devices like the Kindle are worth jailbreaking for the extra features, the risk of bricking is high in many cases because of artificial barriers put in place by the manufacturers. Couldn't they just allow us to use the things we buy as we please, even if it meant voiding the warranty? Halt and Catch Fire Mozilla's new designs - Waste of time or a good thing to show that an open source project can be a "designer item" and a "brand" https://blog.mozilla.org/opendesign/evolving-the-firefox-brand/ Kai OS, based on Firefox OS is now more popular then iOS in India. Briefly our "discovery story” and what makes us passionate about Linux, what motivates us to organise the DLUG, attend conferences etc For now you can find us at: info@dublinlinux.org dublinlinux.org/telegram Dublin Linux User Group website PSAs Oggcamp ’18 Sat Aug 18th - Sun Aug 19th 2018 in Sheffield The Dublin Linux User Group monthly meetup KDE Akademy in Vienna, Austria, from Saturday 11th to Friday 17th August. Attributions The music for this podcast was sampled from Bust This Bust That - Professor Kliq which was released under the CC BY NC SA License.

chikoskiさんをゲストにお迎えして、Unix、C言語、研究員、Firefox、WeJS、ヒルクライム項、などについて話しました。 【Show Notes】 We Are JavaScripters! - connpass html5j ― 「つながる」「学べる」「盛り上がる」 #しがないラジオmeetup 1 - connpass NetBSD - Wikipedia File Allocation Table - Wikipedia X Window System - Wikipedia VMware World Wide Web Consortium (W3C) 岡崎市立中央図書館事件 - Wikipedia CODE―インターネットの合法・違法・プライバシー | ローレンス レッシグ | Amazon Firefox OS - Wikipedia 山登り法 - Wikipedia 配信情報はtwitter ID @shiganaiRadio で確認することができます。 フィードバックは(#しがないラジオ)でつぶやいてください！ 感想、話して欲しい話題、改善して欲しいことなどつぶやいてもらえると、今後のポッドキャストをより良いものにしていけるので、ぜひたくさんのフィードバックをお待ちしています。 【パーソナリティ】 gami@jumpei_ikegami zuckey@zuckey_17 【ゲスト】 chikoski@chikoski 【機材】 Blue Micro Yeti USB 2.0マイク 15374

Ur veckans avsnitt: Att byta internetleverantör - vad-i-helvete, etc. (GLUE, Fidonet.io…) En sedelärande historia för dig som hostar dina egna DNS:er 1.1.1.1, 1.0.0.1 Det var en gång… rymden! På Netflix! Kungligt! Det som kallas "lojalitetsprogram" har vi ett och annat att säga om Vad ska man köra istället för “Android” på sin Android-lur? Jocke vill rensa bort allt Google … Nån som kommer ihåg Evernote? Fog computing Hur kan något så enkelt som cyklar vara så frustrationsproducerande? Länkar Intromusik från eminenta Hired guns IP-only New York-minut - kan ha definierats av Johnny Carson Winther broadband SOA - start of authority Glue FSdata Hover Uptime robot Cloudflares DNS-tjänst nslookup Det var en gång … och En cell-sam historia Professor Balthazar Tomas Bolme Professor Drövels hemlighet Vad är det för fel på groggen du har? Den är slut. GDPR Google, GDPR och svenska medier Google-text om insamling av medgivande “Hjälpsida” om medgivande och information för kakor Medieföretags gemensamma brev till Google Personuppgiftslagen TimeEdit Cyanogenmod Lineageos Jolla Sailfish OS Firefox OS Webos Ubuntu för telefoner Evernote Things Grunge Fog computing Datasjöar Skugg-IT Tanquerey no 10 Fullständig avsnittsinformation finns här: https://www.bjoremanmelin.se/podcast/avsnitt-123-frustrationsproducerande-registrarer.html.

Michael Wehram ist zu Gast und wir reden über neue Linux Geräte, Ubuntu 18.04 LTS Final Beta, Geschichten von den Chemnitzer Linux Tagen, Firefox OS, unnötige Designentscheidungen, Chrome scannt lokale Dateien, Cloudflare's neuen DNS Service und vieles mehr!

It’s Ikey’s last show and Jesse’s last show for a while, and Félim is off sick. Graham Morrison joins us to discuss 2 factor authentication, Firefox OS, a new DNS service, Linux-Libre security, and whether we can move away from centralised social media.   News 2 factor authenticator for Linux The final nail in the... Read More

Nesta edição:   ESTAMOS DE VOLTA! Donald Trump (de novo) interferindo no mundo da tecnologia, as mortes do Google Now Launcher, do Firefox OS e do Wii U, novos planos de internet fixa e móvel de NET e TIM, a MWC 2017 está esvaziada e a Apple está bem como o iPhone, mas… até quando? […]

This week Rafael and Jeremy, two refugees of the browser wars, share tales of sacrifice and chivalry from the early days of the internet. A Muppet Family Christmas https://www.youtube.com/watch?v=ojtGHXsTXmU Bike sharing in China https://www.nytimes.com/2017/09/02/world/asia/china-beijing-dockless-bike-share.html?mcubz=1&_r=0 Browser wars https://www.wired.com/2009/01/awesome-infogra/ Mosaic browser https://en.wikipedia.org/wiki/Mosaic_(web_browser) Hotline https://en.wikipedia.org/wiki/Hotline_Communications Serial Box https://twitter.com/peteavey/status/24423749486903296 SVG https://developer.mozilla.org/en-US/docs/Web/SVG Webkit https://webkit.org/ Firefox https://www.mozilla.org/en-US/firefox/ Imagemagick https://www.imagemagick.org/script/index.php WebVR https://webvr.info/ Netscape https://en.wikipedia.org/wiki/Netscape AOL CDs https://techcrunch.com/2010/12/27/aol-discs-90s/ Compuserve https://en.wikipedia.org/wiki/CompuServe Apple eWorld https://en.wikipedia.org/wiki/EWorld Information Superhighway, 1991 https://www.youtube.com/watch?v=dk82TI92GO4 Information Superhighway, attributed to Nam June Paik and Al Gore https://en.wikipedia.org/wiki/Information_superhighway Adobe Flash https://en.wikipedia.org/wiki/Adobe_Flash_Player Why Chrome uses so much freaking RAM http://lifehacker.com/why-chrome-uses-so-much-freaking-ram-1702537477 The Story of Firefox OS https://medium.com/@bfrancis/the-story-of-firefox-os-cb5bf796e8fb Mobile First design https://www.uxpin.com/studio/blog/a-hands-on-guide-to-mobile-first-design/ Steve Jobs promotes Web 2.0 / Ajax apps (no SDK) https://www.youtube.com/watch?time_continue=42&v=8Vq993Td6ys App Fatigue https://techcrunch.com/2016/02/03/app-fatigue/ Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5 https://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on-html5/ React Native https://facebook.github.io/react-native/ Rafael’s new app, Here Hear http://www.newrafael.com/herehear/ ** Commercial Break ** Reflections on the Burden of Men https://www.rotbom.com/ Jack Conte on reality of being famous on YouTube https://www.ted.com/talks/jack_conte_how_artists_can_finally_get_paid_in_the_digital_age Microserfs, Douglas Coupland, 1995 https://www.goodreads.com/book/show/2748.Microserfs JODI http://v2.nl/archive/organizations/jodi.org The Web Browser as Aesthetic https://creators.vice.com/en_us/article/z4yagw/digart-the-web-browser-as-aesthetic-framework-why-digital-art-today-looks-different Text Free Browsing http://textfreebrowsing.com/ Kobo https://www.kobo.com/ A/B testing and Multi-armed bandits https://vwo.com/blog/multi-armed-bandit-algorithm/ Tinder https://www.gotinder.com/ Why doing less drives more conversions https://neilpatel.com/blog/less-drives-conversions/ Olia Lialina, Summer, 2013 http://www.emiliegervais.com/olia/summer/ Rhizome’s Net Art Anthology https://anthology.rhizome.org/ The Browser Wars are back https://www.wired.com/2015/09/thompson-3/ Torrent files https://en.wikipedia.org/wiki/Torrent_file

Händelserna i Stockholm. Jocke uppgraderar mac pro till HD 5770-grafikkort: som en helt ny dator. Därpå följande diskussion om grafikkort. Lite apprekommendationer. Amigaspel för barn. Jockes pojkar har spelat IK+, Giana Sisters och Stuntcar Racer. Kan publiken rekommendera fler spel? Hör av er med rekommendationer på fina Amigaspel! Vi snackar PowerPC-utmaning, skulle vi klara oss en vecka på att köra våra liv på en PowerMac G5 och Leopard? (eller Linux, eller whatever.. bara det går att köra på en PPC) Vi kommer med veckans, eller kanske århundradets filmtips, och vill gärna veta vad du tycker och tänker om filmen. Ubuntu lägger ner sin egen skrivbordsmiljö Unity. Vad gjorde det i praktiken oanvändbart? Går det dåligt för Ubuntu? Blir världen tråkigare nu när de dessutom släpper fokus på mobila enheter och en hel del annat? Nu hade Firefox OS behövts ännu lite mer. Sist men inte minst: ha en glad påsk och ät synnerligen god mat! Och en tupplur som plan för personlig utveckling. Länkar Kära slölyssnare Händelserna i Stockholm Nvidia Geforce GT 120 Radeon HD 5770 - Jockes "nya" grafikkort Nvidias nya grafikkort funkar med gamla Mac pro Quadro 4000 Geforce GTX 680 Nvidias Pascal-arkitektur Tobias pratar grafikkort i Kodsnack GTX 1080 GTX Titan X United airlines sliter och släpar av passagerare Sedna PCI express SATA 3 SSD adapter Serious Sam KDE Fuzzytime - skön inexakt klocka för Macos Ipulse - systemövervakare för Macos som gör en glad Iconfactory gör en del trevliga appar, och enormt fina ikoner Stunt car racer International karate+ TAC–2 Giana sisters The final cartridge Bubble bobble Micro machines 2 Sensible soccer Kick off Speedball 2 Puggsy AGA PowerPC-utmaning The Shawshank redemption 12 edsvurna män Citizen Kane North by northwest Assassin’s creed Parkour Daft science! Brett Terpstra Systematic Doublecheck your head Ubuntus skrivbordsmiljö Unity går i graven Gnome KDE BQ aquaris M10 - en platta som körde Ubuntu Sveriges mest beundrade man - dokumentären om PG Gyllenhammar Containers - en podd om … containrar Fullständig avsnittsinformation finns här: https://www.bjoremanmelin.se/podcast/avsnitt-73-ragekonvertering.html.

Apple and Samsung lawsuit is being sent back to district courts. Samsung might be secretly showing off a bendable phone at MWC. If the iPhone costs $1000, might an expensive OLED display be to blame, and what's the deal with this new proprietary "Made for iPhone" connector? Those stories, plus we answer YOUR viewer questions, so make sure you're charged and ready for the Pocketnow Weekly Podcast! Watch the live video broadcast from 10:00pm Pacific on February 9th, or check out the high-quality audio version right here. For folks watching live, you can comment and ask questions by using the #PNWeekly hashtag on Twitter during the broadcast. For folks watching later, you can shoot your listener emails to podcast [AT] pocketnow [DOT] com for a shot at getting your question read aloud on the air the following week! Pocketnow Weekly 239 RSS Feed iTunes Link XBox Music Link Direct Download Recording Date February 9, 2017 Host Juan Bagnell Jules Wang News 5:56 | Why the iPhone might be priced at $1000? Super spendy OLED display... 22:51 | Apple got rid of the headphone jack but will launch a new proprietary connector? 29:13 | Will Apple ever be able to see used iPhones in India? 36:51 | Apple vs Samsung Damages sent back to district court 43:53 | Will Samsung secretly show off a bendable phone at MWC? 44:48 | Samsung settles on conservative battery capacity for S8 49:28 | Verizon testing HTC powered by Qualcomm 835? 1:15:19 | Google working with NetEase on Play Store for China? 1:18:02 | Mozilla cutting jobs and shifting Firefox OS to IoT 1:22:36 | Redmi Note 4X Hatsune Miku edition just in time for Valentine's Day? RIP Google Launcher & Benchmark Rigging (01:26:59) In our Video Redux this week, we say Rest in Peace to the Google Now Launcher, and we take another look at benchmark rigging smartphone stats. Should that be considered false advertising? See omnystudio.com/listener for privacy information.

In dieser Folge werfen wir einen Blick auf die Geschichte von Namco und Gedenken den Pacman "Erfinder" Nakamura Masaya. Zudem schauen wir auf die Konsequenzen von Razer die Nextbit kaufen, gucken was es neues bei LibreOffice 5.3 gibt und überlegen was ARM Chips in Zukunft in Macbooks machen könnten sowie vieles mehr. Themen: Pacman Erfinder Nakamura Masaya ist tot Razer kauft Nextbit LibreOffice 5.3 ist da mit Ribbon Oberfläche Apple will noch mehr ARM Chips im Macbook Libinput erkennt nun das schließen des Laptop Deckels Mozilla killt den Rest von FirefoxOS und feuert Mitarbeiter Pfeife der Woche: Cryptkeeper bzw. encfs Distro der Woche: 4MLinux 20.3 Sailfish der Woche: Serra Wie immer wünsche ich viel Spaß beim reinhören ;)

We celebrate 10 years of the Going Linux podcast, and review some significant happenings for Linux in 2016. Episode 315 Time Stamps 00:00 Going Linux #315 · 10th Anniversary Episode 00:15 Introduction 00:42 10 years in review 01:39 6 years of Computer America 02:57 The year of change for Bill 04:02 Ubuntu includes support for ZFS 04:59 Open source licensing 08:15 Creative Commons licensing 11:44 Linux kernel license 13:52 10 years of co-hosts 20:18 Another pay increase for Bill! 20:51 10 years of Larry 22:55 Notable accomplishments 25:14 2016 Review 25:53 Fedora is first to ship with Wayland 29:42 Firefox OS 31:56 Mythbuntu shuts down 34:00 Microsoft loves Linux 42:04 KDE turns 20 42:45 Linux turns 25 46:47 Bill's favorite Linux 48:30 Larry's favorite Linux 53:38 2016: A good year for Linux 55:19 goinglinux.com, goinglinux@gmail.com, +1-904-468-7889, @goinglinux, feedback, listen, subscribe 56:52 End

  Actualités Firefox laisse tomber Firefox OS, met 50 personnes à pied (Lien) Microsoft offre la Surface Pro 4 sans stylet (Lien) Radio-Canada organise un premier Hackaton (Lien) Sony va ajouter le support du disque dur externe dans la PS4 (Lien) LG va régler le... Lire la Suite

We celebrate 10 years of the Going Linux podcast, and review some significant happenings for Linux in 2016. Episode 315 Time Stamps 00:00 Going Linux #315 · 10th Anniversary Episode 00:15 Introduction 00:42 10 years in review 01:39 6 years of Computer America 02:57 The year of change for Bill 04:02 Ubuntu includes support for ZFS 04:59 Open source licensing 08:15 Creative Commons licensing 11:44 Linux kernel license 13:52 10 years of co-hosts 20:18 Another pay increase for Bill! 20:51 10 years of Larry 22:55 Notable accomplishments 25:14 2016 Review 25:53 Fedora is first to ship with Wayland 29:42 Firefox OS 31:56 Mythbuntu shuts down 34:00 Microsoft loves Linux 42:04 KDE turns 20 42:45 Linux turns 25 46:47 Bill's favorite Linux 48:30 Larry's favorite Linux 53:38 2016: A good year for Linux 55:19 goinglinux.com, goinglinux@gmail.com, +1-904-468-7889, @goinglinux, feedback, listen, subscribe 56:52 End

Vor einigen Jahren brachte die Panasonic Corporation bereits sprechende Fernsehgeräte auf den Markt, die aktuell mit Firefox OS ausgestattet sind. Inzwischen bieten auch Samsung mit Tizen und einige Hersteller mit Android TV sprechende Alternativen an. Ich möchte herausfinden, ob die Bedienung via App bei einem LG WebOS-TV ausreicht oder ob die sprechenden Kandidaten doch ihre Vorzüge bieten. Mit Mani Chaar besuche ich den Medialand in Marburg und lasse mir die aktuellen Modelle demonstrieren. Die Aufnahmen wurden komplett mit dem Ohrwurm 3 erstellt. Daher sollten Sie zum Abhören einen Kopfhörer verwenden.

The web platform continues to expand into new regions, not only controlling the Internet of Things but also powering a new set of devices. In this episode, Justin Ribeiro talks with Jan Jongboom about Jan OS, an alternative operating system for mobile phones designed to run on devices without their screen attached and FirefoxOS. Resources and Links http://janos.io GPIO blog posthttp://blog.telenor.io/gonzo/hardware/2015/02/10/gpio.html Firefox OS as an IoT platform blog post: http://blog.telenor.io/gonzo/hardware/2014/12/16/firefox-os-iot.html Presentation I gave about sub-GHz networks and IoT connectivity: http://presenter.qbrick.com/?pguid=cb3beeba-fe2f-43a9-9e4d-690ec3572476 http://www.bunniestudios.com/blog/?p=4297 On This Episode Jan Jongboom (@janjongboom) Justin Ribeiro (@justinribeiro)

Horst JENS, Stefan HASLINGER, Gregor PRIDUN, Anna GEIGER und Denis KNAUF plaudern über freie Software und andere Nerd-Themen. Shownotes auf http://goo.gl/deGLf5 oder http://biertaucher.at

In this episode Chris discusses the death of Mozilla’s Firefox OS for phones, Google’s attempts to safeguard users of the internet, rumor regarding the return of Deathstroke to Arrow, and the possible cancellation of Marvel’s Agent Carter.The featured story this week is that Deadpool has been absolutely crushing it at the box office.  Rumors are swirling that 20th Century Fox might have already greenlit a sequel to the movie! To get more information on any of the articles referenced in the show, check out our shownotes: http://bit.ly/NerdAlert22If you want to get in touch with the show there are a variety of ways to do so:Web: http://nerdalertnews.comShownotes: http://shownotes.nerdalertnews.comE-mail: nerdalertnews247(at)gmail.comTwitter: @NerdAlertShowFacebook: www.facebook.com/NerdAlertShowVoicemail: TBDSubmit Your News: http://submit.nerdalertnews.com

A distribution of Linux built to survey and track speech, we go into the surveillance marvel that is Red Star OS. Solus hits 1.0 & we bring on some of the team to tell us all about it. Plus Mozilla has a new… Distraction? We debate their merits of rumored new Firefox OS powered hardware.

Brian Leroux (@brianleroux), Adobe Phonegap Team Member & open source software developer, spends lots of time on the Apache Cordova and Adobe PhoneGap projects. Hailing from Canada, he loves his hockey and beer- maybe even more than coding. He has spoken at many conferences and is an expert in delivering & teaching mobile web development.   Brian goes into depth on the Phonegap project. Brian discusses how developers can get started building great mobile experiences with Phonegap. He also details the benefits / downfalls of different approaches to mobile development using web technologies as well as tooling, testing, and automation. Resources PhoneGap - https://phonegap.com PhoneGap Build - https://build.phonegap.com/ Ionic Framework - http://ionicframework.com/ Cordova - https://cordova.apache.org/ Introduction to PhoneGap Build - http://tv.adobe.com/watch/building-mobile-apps-with-phonegap-build/introduction-to-phonegap-build-building-your-first-app/ Kony - http://www.kony.com/ ReApp - http://reapp.io/ Appcelerator - http://www.appcelerator.com/ Sencha Touch - http://www.sencha.com/products/touch JQuery Mobile - http://jquerymobile.com/ Kendo UI - http://www.telerik.com/kendo-ui Onsen UI - http://onsen.io/ Famo.us - https://famo.us/ Firefox OS - https://www.mozilla.org/en-US/firefox/os/ Crosswalk - https://crosswalk-project.org/ ReApp - http://reapp.io/ Phonegap  Experts (company) - ` http://phonegapexperts.com/?gclid=CjwKEAjw876oBRCYr86w6KGfpkgSJAACIidwP41ihwn_EWhsPDM_3QAL5hG3imgiVfqIRK4tAhUtnBoCF6rw_wcB Brian Brock's App Adventure - https://www.youtube.com/watch?v=HgNGJosQ6BE Touchstone.js (React Hybrid Apps)- http://touchstonejs.io/ Appguyver - http://www.appgyver.com/ Phonegap mobile accessibility - https://github.com/phonegap/phonegap-mobile-accessibility Article on modules in JavaScript - https://medium.com/@brianleroux/es6-modules-amd-and-commonjs-c1acefbe6fc0 Panelists Erik Isaksen - UX Engineer at3Pillar Global Danny Blue - Front End Engineer at Deloitte Digital Rachel Nabors - Web Animation Developer Advocate & Founder of TinMagpie

Yehuda Katz and Tom Dale join us to talk about the road to Ember 2.0 and "Fast Boot". They share insight about why they stick to a 6 week release cycle, and why they think JS frameworks might be the future of all web apps (especially content sites). We also chat about what "indie open source" means, and exactly how much design goes into the Ember project and community. Yehuda Katz (Twitter) Tom Dale (Twitter) Tom Dale's Klout score is 66 Tilde.io Erik Bryn Yehuda at Hack Summit: "Indie OSS" HTMLBars FastBoot: Ember's Server-Side Rendering solution Tom on Shop Talk Show on Server-Side Rendering Rendr JS Yehuda's RailsConf keynote: "10 Years!" Skylight.io: Make your Rails apps faster with actionable insights Transcript: FILE NAME: The Frontside 16 - Yehuda Katz & Tom Dale Talk About Javascript DURATION: 55:59 minutes CHARLES: Everybody, welcome to Frontside the Podcast, Episode 16. We've got Brandon and Stanley here with me on the podcast and some very special guests who need no introduction, so I'll let them introduce themselves. TOM: Maybe we just start with Yehuda because he's the most famous. Are we starting by number of Twitter followers? STANLEY: Actually, Cloud score. TOM: Yeah, it's Cloud score based. YEHUDA: I think Tom has a higher Cloud score than me. BRANDON: All right, Tom. Go for it. TOM: Hey, what's up? I'm Tom. I had the idea for Ember JS in the shower. [Laughter] YEHUDA: Hey. I'm Yehuda. I work on standard stuff and Ember a lot these days, and now Rust also. TOM: Yehuda just joined the Rust core team. I don't know if you guys saw that. BRANDON: I did see that. Rust is a programming language. YEHUDA: Programming language. STANLEY: Are we going to get to talk about that later? BRANDON: Sure. TOM: We can talk about whatever you want. I'm not going to have any insights on that. YEHUDA: We'll have some insights. TOM: Yeah. I don't know if you guys ever saw the Pokemon Movie, but basically Yehuda is reenacting that with core teams. You've got to catch them all. [Laughter] BRANDON: That's great. STANLEY: That's not just the movie, Tom. That's literally everything around Pokemon. TOM: Oh, okay. STANLEY: That is the tagline. TOM: I will definitely defer. You seem like an expert here, Stanley. STANLEY: You know; I know the most important facts of all time. BRANDON: Stanley is on the Pokemon core team actually. STANLEY: I actually just made a new Pokemon that's like a guitar, a chair, and a microwave put together. BRANDON: What's it called? STANLEY: Rock-On. TOM: That is the worst Pokemon name I have ever heard. [Laughter] TOM: Oh, my gosh. BRANDON: All right, well, off to an auspicious start here. So the two of you and Leah formed the original core team for Ember. Is that fair to say or were there other people involved at that time when you kind of were switching SproutCore 2.0 to Ember? YEHUDA: I don't think I would call the original group that switched SproutCore over to Ember necessarily the core team. I would say that there was a bunch of people that were working on what was called SproutCore 2 at the time at Strobe, and it doesn't -- what we were doing there doesn't really meet my requirements for a good core team or a good Indie Open Source project. But one of the things that we did after switching over to being Ember and announcing the separate project was to make the core team more like what I would want. TOM: Well, I would say that there was never one moment where we were like, hey, let's create a core team. I think one thing that I learned from Yehuda about managing an open source project is that it is extremely important to start delegating way before you feel ready or comfortable. So there was a point early on where we were just totally overwhelmed as people started using it and people came along and were interested. And so we just gave them commit bit without really thinking about the bureaucracy of it or the structure of it. And then it definitely got to a point where it was like, "Why is there no core team yet?" because there's a ton of people with commit. So we should probably think about this a little bit more. YEHUDA: Of the people who are on the core team now, Erik, Chris, and Steph were all involved extremely early. I think Erik Bryn was the second contributor. Well, the first contributor after people working at Strobe, and Chris and Steph got involved really early because they were building an app on Ember that was very, very mobile focused. Well, it's a mobile app, and so they needed heavy performance, and we were not necessarily focusing on that, so they got involved pretty early also. BRANDON: And you gave a really awesome talk about this recently at Hack Summit. We'll throw the link to that in the show notes. I thought it was terrific, and I thought there was a lot of amazing ideas that were clearly born of painful experience. And I want to talk about that in a moment and kind of basically running and maintaining an open source project that keeps the open source ethos, I think, was kind of the thrust of the talk and keeping the Web and Open Source Indie. But before we jump into that, I wanted to get kind of a -- without going into, like, a full state of the union, there's a really lot going on in the world of Ember right now. It can be actually kind of hard for individual developers to just keep up with the news of it. There are just so many cool things happening at once. And there are a few things in particular that I wanted to get an update about. You guys are doing some really interesting stuff right now, but some things that are shipping soon: HTMLBars is actually happening. YEHUDA: It's in the beta. BRANDON: Yeah, it's in the beta, so people -- we tested it in our app already, and with one exception with, I guess, Ember list view isn't quite ready for it yet, but. YEHUDA: I think that's ready now too. BRANDON: Oh, really? TOM: Yeah, that just got updated. BRANDON: So, yeah, it was phenomenal. I mean it just works. Like, it was pretty amazing. So the benefit to users for that has been kind of already gradually been implemented where the metamorph tags in the DOM were gone. TOM: Right. BRANDON: What else can people expect to see once HTMLBars is in place? YEHUDA: So let me just reiterate a thing that you just said that maybe people weren't clear about before I let Tom a little bit about HTMLBars, which is, one of our major goals now and probably forever is to continue to update things incrementally and without breaking apps. And that's something that takes a lot of effort, so I want to reiterate it because it's probably the driving force of everything that we do, so like you said, there's a lot of news. We've been talking about a lot of stuff. We can talk for hours on it, probably. But the key thing is that a lot of times you hear there's a lot of news in a project, and it feels overwhelming. It feels like, oh, my God, if there's that much news, it probably means I'm going to have to spend the next five years catching up with all the things that are happening. And with Ember, our major goal is to make sure that all that, all those new features don't affect your app. I mean there will be a 2.0, and at 2.0 there may be some breaking changes, but even with the 2.0, all the breaking changes will land before 2.0. They'll land on the 1x brands together with deprecation warnings so you'll learn about them as you upgrade. TOM: Yeah. YEHUDA: And so I think this is the driving force of everything we're doing now. TOM: Yeah, I think, with 2.0, it's not like oh, my gosh, there's all this new stuff I have to learn. Instead, what it's going to be is us removing stuff that you probably never even learned about anyway. YEHUDA: Or that we told you in 1.10 or 1.11 to switch away from and you had plenty of releases to remove. TOM: Yeah, you'll have ample warning, and you'll definitely -- it's not going to blindside anyone. But I think this is exactly the point is we're on a six-week release cycle, and it is impossible to do big bang stuff in six weeks. Right? Think about any big software project anyone listening to this has worked on. It's hard to build a huge thing in six weeks, which maybe seems like a limitation, but actually I think we both see that as a huge strength, which is that it really forces you, as an engineer, to think about, okay, I want to move mountains. But I need to do it six weeks at a time, so how do I basically touch back down to reality as often as possible? With HTMLBars, if you think about it, it's a pretty dramatic thing, right? We're basically entirely replacing the rendering engine of this pretty large JavaScript framework, which in some sense is like trying to change the engine on a 747 mid flight. And the only way that we can get away with doing that is to do it very incrementally. And the only way we can do it without breaking people's apps, I should say, is to do it incrementally. Step one was metal-views, which removed metamorphs. But, fundamentally, all view rendering was still string concatenation. And then the next step after that was to get actual HTMLBars in with creating DOM instead of creating strings. YEHUDA: There was actually another step in between, which was to change all the -- so the internal, whenever you use a curlies and handlebars, those curlies, in the old version of the templating engine, would go and they would have ad hoc code to observe something, observe paths, and there was all this complicated code at each point where a curlies was used anywhere in the templating engine, and the new system -- and this is again behind the scenes, so it's easy for even Tom to have forgotten about it. We refactored everything internally so that it used a stream-based system so that all the parts of the templating engine don't have to know exactly how that's all structured internally. And that makes it a lot easier to do performance optimizations, but also makes it a lot easier to avoid mistakes and bugs that cropped up from time-to-time. So that was another step in the direction that was necessary to get all the way to the end. TOM: So now that's in, and I think the next step is to actually -- the next step will be now that we've got HTMLBars integrated in a backwards compatible way, the next step is introducing nice, new syntax. So just one example of this is this gives us the ability to remove the bind-attr helper. Most people that I've noticed when I'm teaching them Ember intuitively think that they should be able to do attrf equals curly, curly URL, and that doesn't work together. You have to do bind-attr. But because HTMLBars is a much smarter parser, we're able to have that context, and we can actually just dramatically simplify the whole model. BRANDON: Okay. And you also answered another question I had, which was, there are a lot of people basically talking about how they should be building apps for 2.0 friendliness, but it sounds like if they stay with the point releases, there'll be very little work involved in moving to 2.0. So you don't have to kind of like today sit and architect your app in a certain way as long as you're staying up to date with the point releases. Would you say that's relatively accurate? TOM: Yeah, I think so. 2.0 is not going to have any new features, and one feature that Teddy Zeenny is working on for the Ember Inspector, you know the Chrome and Firefox plugin for the developer tools, is adding a deprecations pane. So what we expect to happen is that people should just keep upgrading their apps on the 1x point releases and then, every upgrade, you may see one or more deprecation warnings pop up, either in the console or in this pane in the developer tools. And you just fix those at your leisure. Then when 2.0 comes out, all that will happen is that the payload size of Ember will shrink. YEHUDA: Yeah. I think another way to put all that is, when we looked at React, so we looked at React a lot as part of the run-up to 2.0 for the past, like, six months. And when we looked at React, initially we saw a programming model that actually wasn't that different from how we thought people should build Ember apps, so things like you should have data flowing down from a single point and, in Ember, that single point is the model hook in your route, and then we always thought about data flowing down. And you should have events bubbling up, and you should use actions mostly for communication. I remember Erik Bryn very, very early on said, "I think people are overusing data bindings. People should use events more." And that's when we started adding the evented system to a bunch of the parts of the framework. TOM: Actions. Actions weren't there originally … two-way bindings. YEHUDA: Well, we added actions, but we also added, like, Ember.evented. TOM: Yeah. YEHUDA: And I think we kind of knew all this, right? And so idiomatically the way that Ember 2.0 works is actually not that different from how we thought Ember 1.x should work, but I think one of the things that ended up happening is that because data bindings are so -- two-way data bindings can be very nice and clever, a lot of times people would reach for two-way data mining because it was the first thing that was sitting there. And then they would end up building somewhat complicated systems that rely on communication through two-way data mining. TOM: The syntactic sugar pushed you in that direction. YEHUDA: And so a lot of what Ember 2.0 is is about making syntactic sugar more honest about what is the right default, and that does mean that there may be applications that were heavily relying on communication, especially communication channels through two-way data bindings. And that will work much less nicely in Ember 2.0, and it might feel painful to upgrade if you're trying to be both idiomatic and upgrade to 2.0 at the same time. But I think, for most people who are using actions and were using data down through the model hook, I think a lot of it will feel very familiar, will feel very much like how you've been doing things all along. CHARLES: Cool. I actually had a question about HTMLBars landing, and that's when we upgrade our apps, everything should just work seamless. Like Brandon said, we actually did a spike of that, and it mostly seems to be the case. You said that there are no new features, but are there more, like, newer development stories around? Like, given that the templating engine or the view layer understands the DOM, what power or APIs will users have to interact with it, like to do animations or bring things in and out and stuff like that? YEHUDA: Oh, yeah. CHARLES: Is there any of that stuff planned? YEHUDA: I don't think we meant to suggest that there are no new features in number 2.0. Just that they will land in the 1x series, I think, is the point. CHARLES: Ah, right, right. I see. TOM: I think probably the biggest feature is just speed. And I think, also, what HTMLBars' architecture unlocks is the ability to better integrate with other libraries by adopting kind of a diffing approach similar to what React does with the virtual DOM. Basically, in my mind, HTMLBars is all about a bunch of infrastructure work that allows us to make the programming model feel more natural for people who are…. YEHUDA: One way to think about it is that it's the first templating engine that was ever built specifically for Ember. Handlebars templating engine before was built as a general-purpose templating engine, and we pushed it as far as it could go to be real useful for Ember. But things like bind-attr and the metamorph tags kind of crept in as necessary because the templating engine wasn't really built for this purpose, the exact purpose that Ember was designed for. And the HTMLBars engine, part of it is that it's DOM based, and part of it is that it supports diffing, and part of it is that it's faster. But I think, ultimately, it allowed us to look at a lot of areas that are annoying about using templates in Ember and make them nicer. And, yeah, so I think that it's -- TOM: I'd say it also unlocks things like we're working on server side rendering right now, and a lot of that is due to the power of HTMLBars because we can run it in so many different environments, and we can model all of these things as streams internally. It gives us a lot of flexibility about what we can do with your applications. You know, we can do things like server side render your applications even though, of course, you never designed your app for that case in mind. But because of how expressive the templating and, in fact, the entire application architecture is, and because we all agree as a community that this is how we architect our apps, it unlocks a lot more stuff. And I think there'll be more things like server side rendering in the future that we all benefit from by sharing this very declarative application structure and very declarative templating language. YEHUDA: Yeah, I mean honestly, under the hood, the fact a lot of the innovations of the templating engine are not things that any user will ever see directly because they're just implementation. And if we wanted to go around pimping things like streams or the way that the diffing algorithm works internally and the way we clone fragments and all this stuff, we could probably spend a lot of time pimping it, and maybe that would even make a lot of people, some people happy. But I think you'll see, over the next year or so, these things will all lead towards better features or to more features that will be nice, and that's how I think we'd like to roll -- TOM: I think Web components integration is a big one. YEHUDA: Ah, yeah, that's a good point. TOM: I think HTMLBars makes it very easy. And so, in terms of actual improvements coming on top of HTMLBars, the component syntax, instead of being curly, curly to indicate that you want a component, you'll be able to use just regular angle brackets, so that'll be nice. And another thing that we're really keen to get rid of is: You know how today when you're building an Ember component if you want to customize the element associated with that component, you have to say, like, tag name, class name, bindings. You guys know what I'm talking about? BRANDON: Mm-hmm. TOM: So that's kind of annoying because all of those special properties on the component class that you used to customize the element are all duplicating features that already exist in the templating language. So it's just kind of this weird bifurcation of the programming model where, if you want to customize the element for this top level, do it in JavaScript. Everything else, do it in the template. So HTMLBars will allow us to allow you to customize your component element purely in the template, and you won't have to -- basically there are far more cases now where you'll be able to get away with a component that's just a template file, and you'll reduce the number of JavaScript classes in your app. YEHUDA: Yeah, I think, from a high level, the biggest -- the high level of the internal technical improvements are largely that it allows for contextual work. So the old templating engine wouldn't necessarily know that you're inside of an attrf when you have curlies, so we would have to spit out a bunch of extra stuff and maybe make you use extra helpers. It wouldn't necessarily know that you're in image FRC or a video tag or a component. It wouldn't be able to tell if you were using a polymer component that implements the bind protocol, right? But the new templating engine basically lets us see exactly what's happening at every curly, and that just has a large number of positive effects. BRANDON: So you said something else that I felt like was a good segue into the next part of the discussion that this basically allows you to do server side rendering, which you guys are really, like, in the thick of it right now. But for me, a lot of the talk I've seen a about server side rendering comes across as a little inside baseball. There's this sort of discussion between people who are really into React because they're suddenly doing a lot of stuff with server side rendering, and they're seeing some benefits out of it. And you see this stuff kind of pop up in the JavaScript community, but I'm curious to know if you guys can explain a little bit about the benefit of server side rendering that this is a major new feature coming to Ember now. YEHUDA: I'll let Tom maybe give the full pitch, but I think one thing that I feel somewhat strongly about is that, for most people, if you don't have a system that actually gives you something that works pretty well out of the box, in other words it doesn't ask you to do a lot of the work yourself, the idea of isomorphic server side rendering where you run your same app on the client and the server, I don't think that that ends up being worth it. And if you look at a lot of apps that use Ember today, a lot of them have spent relatively little time building non-isomorphic solutions for specifically SEO that have been very, very cheap in terms of time and very, very effective. But I think there's the: I want to not have to write that, even that little bit, and I think that that you get a lot of benefits out of if you just have your framework do it. In other words, if it's not just like your framework does 20% and you do 80%. If it's your framework does 95% and you do maybe a little bit, or you have some constraints, I think that is worth something. And I think the rehydration of fast boot is worth something, although that has even more issues and even a larger percentage that most people have to do on their own. Basically, I think the TLDR for me is that I've always saw server side rendering as indeed somewhat inside baseball because, for most people historically, and I think this is even true largely about React, the solution that you're offered is the framework will do a little bit for you, and you have to go figure out a lot of the details about how to make this work for real. And I think most people just don't have the time to figure all those details out. TOM: So it's been kind of interesting to watch this play out over the last year or two because I think there's been a big split between the JavaScript application community and old school people that create content for the Web who are really keen on this idea of progressive enhancement. And so there's kind been this split. And, for me, for a long time, I personally didn't really care about this case because, in my mind, JavaScript apps were really good for what I'll call workspace apps, which is most of them are behind a login. You log in. You have these very rich interactions. You're editing something. You know, I worked on the iCloud apps. It's a feature, not a bug, that Google can't index your calendar and your email, right? So to me that was the use case for JavaScript apps. But that was until I saw content sites. Like, I remember the first time thinking, "Wow, maybe JavaScript apps are actually the future of all Web applications," was when I saw Bustle, actually. When I saw Bustle, it was just a content site. It was just news articles. And if you would've asked me, I would have said you should probably use Rails or some other server rendered framework for this. But then I saw it, and it felt just like a website. I couldn't actually tell the difference other than how damn fast it was. And I kind of had to step back and question all of my opinions about how people should be building these kinds of applications. And especially for content sites, I think that the server rendering is really important, right, because historically your user has had to download all of this JavaScript and all that JavaScript had to be downloaded and evaluated and run before they saw anything. So having the ability to bootstrap that process on the server and have the first bits that the user starts downloading not be the JavaScript payload, but be HTML and CSS, so that the first thing that they see is useful, I think that's really going to change how people build applications because you get the benefits of server rendering while still retaining the kind of interactions that you can build with something like Ember that you just can't do with Rails. YEHUDA: But again, I think people trying to do this on their own and taking maybe a half solution and then trying to figure out how to make this work reliably ends up producing things that are pretty buggy and feel pretty bad on first boot, or they end up requiring tremendous amounts of engineering resources. And it's possible that, like, huge companies can make this work. But I mostly think about startups, and startups simply do not have the engineering resources to take on the server side rendering task on their own, so this is why I think we care about it for Ember because, as Tom said before, Ember is already pushing you down a pretty conventional path, and we think -- our hope is that by having people do that conventional path and us taking charge of server side rendering will have something that works mostly out of the box for a lot of users. Again, assuming they follow some additional constraints about what you're allowed to do on the server. TOM: And I think we should be clear here because there's, as always happens, there's ambiguity in the terminology. So first is the term isomorphic app, which I don't really love that term, but I guess we better get used to it, Yehuda. YEHUDA: Yeah. TOM: But there's really a spectrum. On the one side of the spectrum you have something like Airbnb has a library for Backbone called Rendr (with no e - well, one e, but not the second e). And that kind of lets you wire up some of the server side rendering. But again, it's very, very manual. And the whole purpose of this is just to make sure that the first thing that you deliver to the browser is HTML and not JavaScript so that the user, even if they don't have JavaScript enabled or they're on a slow connection or whatever, they get something useful. But then on the other side, you have things like Meteor or Asana where the whole idea is -- and to me, I'll be honest with you. It strikes me as extremely silly, but the idea is that you're writing both your server and your client in the same code base, and then you're deploying them both. You describe it, and it sounds like this magic bullet, but it also just seems really silly to me. YEHUDA: Well, I think the fact that even the first releases of Meteor had if Meteor.isClient and if Meteor.isServer, and even the first demos had large blocks of content…. TOM: Yeah. Conditionals. Yeah. YEHUDA: Basically means that people hadn't really figured it out exactly right yet. TOM: Yeah, the point is that even if you have a client side app, your server still has a lot of responsibilities, especially around data access to the database, authorization, authentication, and so on. And putting that in the code base with your UI and your drag and drop code just does not make any sense to me. So I want to be clear to everyone listening that that is not what we're going for. The idea is not that you're writing your json API server in Ember. The point is that you're writing the same old app. In fact, we hope that you don't have to make any changes to your app. And you can deploy it, and it will do a render using the same code. It's basically like your app running in a browser on the server, and then we'll have some way of -- YEHUDA: Except not actually a browser. TOM: -- it's actually a transferring state. YEHUDA: Except, importantly, it's much, much cheaper than being an actual browser. We're not using phantom JS or a zombie or anything. TOM: Right. Conceptually a browser, but we don't want to pay the cost. Phantom JS is a source of great pain for many people, ourselves included, so we want a pure JavaScript environment. But conceptually it's a browser. YEHUDA: I think the reason I hopped in there is I just want to be clear that the goal of conceptually a browser is actually not to be a browser, but to make Ember itself internally abstract enough so that the most expensive parts of being a browser can be replicated in a cheaper way on the server. Obviously the most important part of that is the DOM. And that's the part that React worked out for server side rendering is use the virtual DOM on the server and not a real DOM, right? And that means you don't need real phantom JS and the full scope of DOM. But there's also other stuff like how your routing works and how the model hook runs and how it makes requests, how it makes "XHRs" to get the data in the first place. Right? There are a lot of details if you think about what it takes to boot up an app in the first place. For us, the goal is to go through that whole process of booting up an app all the way through, but not including the did insert element hooks in your DOM and make sure that all that stuff doesn't require -- it has really constrained and clear abstractions, right? So rendering has a render abstraction and routing has a location abstraction, and the DOM has the HTML bars, little dom, lower case dom abstraction, right? So instead of saying we're running it inside of something that pretends to be a browser, we're saying Ember doesn't actually care whether it's in a browser or not, but it has very, very clear abstractions for what it means to be a browser. BRANDON: Okay, so is there--? It sounds like it could be a little like -- is this a little ways off? It sounds like there are a lot of benefits. Like, if you see the hand rolled stuff that Discourse has done, clearly this is something that Bustle cares enough about to sponsor, this is probably a little ways off for Ember developers. Is there anything that you want people doing Ember to know right now about server side rendering in terms of how it's going to affect them or some of the technical stuff that you're learning through this or anything like that? TOM: I think we've been thinking about this particular problem for a very long time. And in fact, we've intentionally designed the architecture of Ember specifically to handle this case, even from the beginning, even like three years ago. We knew that this is something that we wanted or at least we didn't want to paint ourselves into a corner around. So I think there are two aspects of this, and one of them, I think, is pretty well bounded and pretty straightforward. The other one is definitely going to require a little bit more research. The first step is simply getting rendering happening on the server. So because we designed Ember for this case, we were actually able to get Ember as a framework booting up in node in about a day's worth of work. So a couple things have crept in. There were areas where we had been a little bit sloppy and introduced dependencies on things like document.body, jQuery, things like that. So it was about a day to kind of encapsulate those, make sure that they weren't hard requirements for booting the framework, and that was about a day's worth of work. And then, by the end of the week -- we've only been working on this for about a week now -- at the end of the week, we actually had an app booting in node and handling route requests. So in terms of progress, it's been really great. But I guess all that we're saying is that, in a week, we were able to capitalize on the last three years of work we've been doing. That's not as impressive as it sounds. YEHUDA: It was nice that there were relatively few regressions, right? TOM: Yeah. YEHUDA: That the list of things where people were accidentally doing things that assumed the browser was actually relatively small. TOM: Yeah. And the way that we did that is basically introducing an abstraction that provides your environment to you, so a node that's different than in a browser. So that's the first part is to get the app booting, and the second part is to get it rendering. I think what's really cool is that, even though HTMLBars, of course, is a DOM based rendering engine, or despite that, we still use an abstraction around DOM access. What we're going to be able to do when we start, again, in earnest tomorrow, on Monday, is basically replace that DOM helper that we used to create DOM in the browser with something that we'll be able to build up strings so that you can build up your HTML on the server and serve that to the client. That's step one: rendering. I think we'll be able to make quite quick progress on that. I would guess probably about -- I don't know if I should give timelines here. I think we're ballparking around a month before we can at least beta it, the server rendering. BRANDON: That's a little faster timeline than I had assumed. TOM: That's purely rendering. I want to make clear that that is purely for things like SEO, for Web crawlers, for curl, things like that. Then the next phase after that, and this is where it gets into the tricky bit, is being able to -- YEHUDA: Rehydration. TOM: -- is rehydration, what people call it. What we call fast boot. And with fast boot the idea is that whatever state that we use to build up your application on the server, we also transfer that state, not just the HTML, not just the output, but the state that we use to build that output is somehow seamlessly transferred from the server to the client. And the client basically just takes the HTML that we've given it and reconnects all these bindings and goes from there, so it's totally seamless to the user. YEHUDA: And I think there's some complexity there. For example, there may be some part of your page that you can't actually render on the server because it says, like, "Hello, authenticated user," with the user's name. So thinking about ways to make sure that you can mark those as needing to be rendered on the client without causing jank. There's a bunch of stuff like that where, at first glance, it seems not too bad, but I guess the high level if there's a determinism issue, right? So the goal is to make sure that roughly what you did on the server is the same thing that you do on the client because if it's too far off, then you end up having to throw -- no matter how smart our algorithm is, we're going to end up having to throw away everything and replace it again. The idea is how to structure your app, how to structure the way that you set up your app in Ember CLI so that you tend to be putting out output that's deterministic on both sides. And, like Tom said, I think state is maybe overbroad. It's mostly modeled batter, right? Making sure that the model batter that you got on the server is equivalent and transferred together with the HTML payload so that the model hooks that you have in your client will not have to go make another XHR. They'll just have the data that the server already collected, and then hopefully rerender an equivalent DOM on the clients with relatively low…. TOM: There are just a lot of tricky cases, like imagine you have a bound helper that shows relative dates, like 30 seconds ago. So you have a clock on the server, and then you have a clock on the client. How do you reconcile those two? YEHUDA: Yeah, so the good news there -- the good news with all that, without getting too much into the weeds, is that the HTMLBars' engine is already broken up between rendering the parts of your DOM that are static, that are like the hello, the text hello inside of an H1, and updating the static parts with dynamic content. And today that's purely a performance optimization, and so that we could use the same document fragment over and over again after cloning, but that will also allow us to use server rendered content where, instead of expecting to have an empty text node that is to be filling in with dynamic content, we'll have a filled in text node. And we see, in that case, Tom, that the time that is in there already is not the correct time. It's not the equivalent time, and so we'll update it. So that's sort of like the React diffing strategy. I'm less worried about, like, there's a single text node with the wrong content because I know we can deal with that. And I'm a lot -- although if it's too much changes, it will look very bad. It will look very janky. I'm more worried about, like, this entire conditional change. So you're looking at something and then, like, your sidebar swaps out for a different sidebar, which I think would be a pretty unacceptable UI. CHARLES: Obviously there are a lot of different server side environments that people use. What requirements of the server is there going to be if I'm using a Rails app or something in Python or Java or whatnot? How am I going to interface to this? TOM: Well, you definitely need a JavaScript runtime, right, because your Ember app is written in JavaScript. Unless you're planning on pouring it into Ruby or whatever, we're definitely going to require JavaScript runtime. And I think we're starting with just supporting node. But what I would like to see, and maybe you guys can write this, is a Rails gem that you can install that will install dependencies in everything and basically get set up in a production environment. YEHUDA: I think one thing people often forget is you can definitely -- you could you have a node app running. People try to embed JavaScript. They try to use, like, The Ruby Racer, and embedding JavaScript is quite a disaster. BRANDON: [Laughter] I'm sorry. I don't know if you know. Charles wrote The Ruby Racer, and it is a disaster. STANLEY: It's cool. It's a disaster. YEHUDA: So let me be clear. It's a great idea. I use it a lot, but it just fundamentally doesn't now work. Right? It fundamentally cannot -- you cannot embed two VGCs in the same process. BRANDON: Right. YEHUDA: Okay. BRANDON: This is the greatest moment in the history of our podcast. I just want to say that. CHARLES: No, I know. There's no way to collect…. YEHUDA: Yes, exactly. CHARLES: -- for example. YEHUDA: I was about to use cycles as an example. CHARLES: The APIs just don't exist. YEHUDA: Yeah, so basically cycles, so this is why. The reason why I feel strongly about this is that we use Rust for Skylight, which is our product. And we need to embed something, and I would never in a million years embed something with a garbage collector. And I think The Ruby Racer was a pretty good -- I think, for constrained cases, it works fine if you know what you're doing, but people basically tried to use it as, "Oh, I'm just going to write part of my program in JavaScript. And, by the way, both languages have closures, so good luck," basically. The Ruby Racer is cool, but I would not -- I don't think that that's the correct strategy for having long-running JavaScript programs like Ember, like complicated stuff like Ember. I think a better thing for people to do would be to figure out a simple IPC protocol so that they could run their Ember app and then have a simple way of talking over a socket or something with the node app, so booting up your Rails app will also boot up the node app. And, if necessary, and you're serving through your Rails app, you could communicate. TOM: I think, to be clear, the Ember app, even when running on the server, still talks to the database server using json, right? So it's the exact same data marshalling flow. It's just presumably it'll be a lot faster because probably your API server and your application server are in the same data…. YEHUDA: Well, at a minimum, it'll be a lot more consistent, right? TOM: Yes. YEHUDA: I think when people -- when Twitter complained about somebody from some country connecting and getting a really slow connection, the issue there was that they were downloading the app shell and then who knows how long it took to download the json payload, right? But if the json payload is coming from the same data center, then it's, by definition, going to be downed within some range, reasonable range. BRANDON: Okay. Awesome. I'd like to shift gears and spend a couple minutes talking about something that most of the questions that I had originally for this were actually answered in your talk. But I'd like to go over it just a little bit. You alluded earlier to the way that you're running Ember as an ideal, sort of your ideals, discovering your ideals about open source projects and the Indie Web. And I think it's a really important topic, and I want to ask a little bit about that because I don't think a lot of people understand this. I think, especially I see in the JavaScript community, a lot more people establishing open source projects that are corporate run and that being considered a benefit rather than a drawback. And I've seen you push back on that a little bit, and I wanted to ask you, Yehuda, about what your definition of the Indie Web is and why you specifically run the Ember project the way that you guy run it. YEHUDA: Sure. I think there are basically two parts of what it means to be Indie, and the second one sort of derives out of the first one, but I think it's -- you wouldn't necessarily arrive at it yourself, so I'll make it explicit. The first one is that you have a diversified core team. What I mean by that is essentially diverse in all the ways you could possibly think of, and things that I learned from other projects are, like, functionally diverse. So make sure that if there's a person on your team -- if there's a person around somewhere running your events or doing documentation or doing evangelism or running user groups, make sure that if there's a person who is very skilled at doing that that they are the top person on your team in charge of that. The counter, the alternative that I've seen a lot in the open source community is that the person running events essentially reports to the core team, right? There's a person who is maybe a professional event runner, and they are not in charge of events. They're in charge of coming up with ideas for events that they run by the core team, and the core team decides yes or no. The problem is the core team has no skills in doing that, so this person ends up spending huge amounts of time being frustrated trying to explain to the core team something or other, right? That would be the equivalent of somebody on the core team writing some area of code, having to come to the rest to the core team and talking about really tiny, nitty-gritty implementation details. Of course, unlike code where I think people have an intuitive sense that you're deep in the weeds of some performance thing, and I don't really understand that. In a lot of areas that are not code, code people have a very high sense of their own understanding, right? The core teams, I've seen a lot of core teams that people come and they say, well, I happen to know a lot about how people want to read docs in this country and so I'm going to help with the translation effort. All of a sudden the core team is an expert on, like, Indian documentation. And they have all these opinions that are totally unwarranted. Step one is have a functionally diverse group of people, and have people that are not necessarily hardcore coders, but are talented and professionals in their area. Have them do that work at the top level. And I spent a little time on this just now because I feel strongly that this is an area that people miss, and it's just an area that code people are too high on their own supply. They're too impressed with their own skills. They cause a lot of pain for the people who are good at areas that are not hard-core code, so that's one. Two is be diverse in terms of the set of people that own decision-making in your project, so this is what you were talking about with the company run open source, and this is something companies can do. I've seen, for example, I worked with the Rust Project, and the Rust Project originally started at Mozilla. But they've been spending tremendous amounts of effort to try to increase the set of people who are on the core team of Rust that are not working at Mozilla. And this is something that maybe takes a lot of effort once you have an established project at a company. There's all the internal company politics you have to deal with. But the reality is that if you have a project that's at one company, you're kind of at the whims and the mercies of that one company's how they do resourcing, whether they think it's important, what their actual goals are. Maybe the thing that they built the project for doesn't necessarily match what the community is doing, right? So become diverse in the companies that own it. I think projects like Rails, Postgres, Ember, increasingly Rust are good examples of this. And, of course, I mean the regular meaning of the word diverse here, just because if you become more diverse in all areas, you actually find yourself being more function diverse just because of who ends up being in what areas. You end up finding yourself having a lot better insight. You end up sitting in a room, and when there are people of diverse backgrounds, the kinds of questions that people ask. And I can only say this. This is the thing that I've noticed personally. It's not a thing that I can empirically measure. I've just noticed that the kinds of questions that people ask, when you're diverse in all kinds of ways, ends up being -- they end up being stronger, better, and they end up pushing back on the kinds of decisions that you can make as a monoculture with group think, right? The harder it is to have group think, the harder it is for everyone to sit around and say, "You know what we're going to do? We're going to rewrite everything," right? That kind of thing is hard to do when you have a lot of people with a lot of different backgrounds with a lot of different interests. So that's, I think, the higher order bit of what in the open source means is be very diversified in a lot of different ways. But there's a specific thing that I think comes out of it that is very important, which is to do the work that you're doing incrementally. Again, the reason I think that this is a derive is that if you have a lot of people with a lot of different interests with a lot of different projects, I think it becomes very difficult for you to do full on rewrites because everybody has interests, and maybe a few people are excited about doing a rewrite, but everyone else says, "Oh, my God. What about my app?" Then you have the docs guy saying, "Oh, my God. Now we have to maintain two sets of docs?" And you have the evangelism guy hearing all the pushback from the community about the rewrite. So it becomes very difficult for you to have this situation where you're not doing things incrementally. But I think, in my talk, I spend some time on what it means to do things incrementally and what the benefits are and how to adopt the six-week release cycle and all that. I talked about that in more detail because, even though I think it's a natural consequence of being diversified, it's also something that you have to think about if you want to do it well. BRANDON: Yeah. It seems to me that that would require, like it's kind of a chicken and egg deal, but to me it seems like there was a lot of discipline in switching to a six-week release cycle, and that's important. It seems, for us at least as consumers of Ember as an open source framework, that's benefited us greatly. We find the framework much, much easier to keep up with on the six-week release cycles than pretty much most other open source projects we've worked with. YEHUDA: Which is kind of like a paradox, right, because you expect that six-week release cycle means you can never keep up with it because it's always changing. But in fact, six-week release cycle means you don't have time to ever change that much. BRANDON: Well, and even for apps that go dormant for a while, we find that, okay; we'll bring it up to one. Bring it up to the next one. The upgrade path becomes extremely obvious. YEHUDA: Yep, exactly, and there's deprecation warnings, and there's ... I think people should watch my talk on this specific area because it took me 15 minutes or something to lay out the whole thing. But I think the basic idea of just doing things incremental, and incrementally has this bad sense. It's like, oh, maybe you're hunting for the local maximum or something. All I mean by incrementally is the same way that the human body replaces its cells, right? You don't do it all at once. Maybe over an extended period of time, the thing that you're looking at is completely different. But because you did it a little at a time, you were able to move the whole community together in the direction instead of people, many, many people getting left behind, which is what used to happen a lot with Rails. I think Rails has gotten better at this over time. But it used to happen, like Rails 3 came out and a lot of people were stuck on Rails 2.3. BRANDON: I think when people hear incrementally, they can think about possibly incrementally be led in circles, right? You could incrementally be every day wake up and decide to change one degree or the other. What matters is if you have a compass that's pointing somewhere. For the Ember project, that incremental stuff doesn't work unless it's pointed somewhere very clear. And you and Tom are basically the keepers of that vision. And I wanted to ask about that, what the vision of the framework is that keeps guiding everybody. Is it sort of implicit to the project? As you use it, you recognize it. Or is it something that you've explicitly outlined somewhere? YEHUDA: I'll take this for a second and then Tom can jump in. I think, fundamentally, the main vision is just we ultimately wanted to have a full stack solution that solved the majority, the vast majority of the problems that a regular person would have writing a Web app, but we knew from the beginning that if we tried to take on that whole project, I mean even Meteor, who took on that whole project, is still struggling to have to complete the vision. And they tried to sort of boil the ocean. And so, we knew from the beginning that we were going to get it wrong if we tried to do a CLI tool and a framework and a data library and all this stuff all at once. And so I think we started off with the V in MVC, basically, right at the beginning and added routing and other stuff over time. But the mission always has been to build the thing that's a full stack of what you need to build front-end tools. Tom, you can take it from there. TOM: Yeah. I think, in the JavaScript world, I think, because JavaScript for so long was treated as a toy language that people didn't do serious stuff in, it attracted a certain type of developer who is -- which is a totally legitimate opinion, but they tended to be kind of hackers who would do these one-off experiments. And because of that, the notion of convention over configuration and having shared solutions is still a somewhat surprisingly controversial opinion in the JavaScript community. And so I think the role, as you said, for Yehuda and I, is to basically be willing to stand up and take the tomatoes that get thrown at us and say, "You know what? No, there is benefit in having a shared solution, especially when it's not just one-off hackers in their basement, but when it's a team of engineers working at a company, and you have a product that you need to ship, and it needs to have good interaction. It needs to be done yesterday. Those people need tools too. People like that deserve tools." And I think that's our goal is to have a framework that will last for at least the next ten years that is willing to incorporate good ideas as they come out and as they're embedded, move the community together, as Yehuda was saying, but without chasing the hype dragon where every six months: "Throw away everything you know because the next big thing is coming out. Rewrite your apps." I see Ember as a way of kind of tempering that instinct for engineers to chase the new and shiny constantly in a way that basically we have a community that agrees together what the next big thing is, and then we start moving towards that. I think, right now, major things that we're thinking about are one server rendering, as we talked about. Getting the CLI tools in place, that's a thing that we've wanted for a long time. But as Yehuda said, we didn't want to try boiling the ocean. And then the new HTMLBars view layer, which unlocks a lot of the cool things that React is able to do around, like, DOM diffing and so on. YEHUDA: Yeah. I usually tell people -- recently, I've come to a line, which is, if you want to tell me that there's not a place for shared solutions in some area or some abstraction, I think the burden is on you, actually. I think people in the JavaScript community, and there's a small group in the Rails community that feels the same way, they assume that the burden is on the person who is trying to abstract, right? If there's a common problem that a lot of people have, they think it's your job to prove that abstraction is a good idea. I think it is your job to prove that a particular abstraction is a good idea. But I think my de facto, my default position is that if a lot of people are solving the same problem that there's a shared solution worth hunting for. And I would say the JavaScript community is really -- big chunks of the JavaScript community are pretty anti this approach. But I think it's really the only way that you could build -- like Tom said, the only way you could build projects with large teams is to have some sense of what the shared answer is and to not have it be some genius on the fourth floor somewhere that does everything. And if you want to make any changes, you have to go to them. I've seen a lot of companies that work like this, and it works fine. Anther facet of this is that pretty much every company deciding to adopt, like, Ember, Angular, React, or Backbone, whatever, they do like this "taste test," right? A taste test is like a two-week project where they see which one is faster. By definition, the taste test doesn't successfully analyze what happens over a longer period or when you have a bigger set of developers, right? It's by definition optimized for short projects with a small number of developers, and so -- TOM: And usually it's the guy on the fourth floor conducting the taste test. YEHUDA: He's either conducting it or he is actively attacking it, right? He is saying we should not -- for example, Firefox OS refused to adopt any framework for an extended period despite the complaints of many people on the Firefox OS team because of the fact that they had a religion against frameworks. They didn't like frameworks as a concept. I've heard this from large numbers of people working on the periphery of Firefox OS and many complaints, right? And so I think we, Ember, one of the things we had to learn was that we can't get away with just saying that. We can't get away with saying, oh, you'll learn. If you just use Ember for a year, you'll figure it out. We had to really improve the getting started experience. But I think, on the flipside of that, there's no way that we could ever -- even if we get to be as nice as to optimal getting started framework, getting started tool, we're always going to have benefits that are not part of that that are very difficult to see when you're doing a quick analysis. Actually, recently we've seen a lot more big companies come out and talk about the benefits of Ember for long-lived projects, and I think that helps a lot just having people testify that they used Ember for a year within a team that wasn't three people, and they found it to be productive in these specific ways. I think that's helped a lot of people feel comfortable. BRANDON: That's been my experience, certainly, as well, just seeing that increase. I think everybody should -- honestly, I believe everybody listening to this should drop what they're doing and go watch the Hack Summit talk. I thought it was phenomenal, and I think it made me think a little differently because it's a little confusing out there, like what some of the tradeoffs are in these open source projects that are run in that kind of echo chamber. And the fact that you guys work so hard to pierce the echo chamber is really cool. I know that there may be some technical questions. We don't get a chance to have you guys on the podcast very often, obviously, so I wonder if anybody has any more questions. STANLEY: Before we get back to technical questions, I just want to cut in and say I really like Yehuda's talk from Rails Conf as well. It was really eye opening for me as somebody new to the Rails community, even though Rails has been around for a while, and kind of understanding the value of shared solutions and kind of the philosophy behind that. YEHUDA: Yeah, that was definitely the first time I tried to formulate a general theory for what shared solutions look like and why they're good, and essentially why Rails hit the nail on the head with the right amount of shared solutions and where the experimentation is happening and all that stuff. STANLEY: Cool. Back to you, Charles. CHARLES: I just had a quick question I wanted, before we wrap up. I had another question about the server side rendering, kind of a general one. I know I've definitely been burned by server side rendering in the past, you know, because it's been something that people talk about on and off, it seems like, for the last five, six years. I remember when mustache first came out. The first time that I tried it, it's like, oh, I've got this templating thing that I can run inside on my Rail server, and I can run it. There's a JavaScript implementation too. One of the things that I found was I was able to get up running very quickly, but then I felt like I was eaten alive by the edge cases. It was actually -- I think it was a blog post that you wrote, Tom, where you were talking about kind of the justification for resolving, always resolving RSVP promises asynchronously. Because, to not do so, have a different context, different stack sitting on top of the resolution was like releasing Zalgo into your application. I actually, when I read that thing about promises, it actually made me harken back to my experience with server side rendering. I was like, oh, with server side rendering I was releasing Zalgo onto my client. I had a very different context. TOM: Yeah, the thing you're describing is sharing templates across two different apps, right? CHARLES: Right. TOM: The data model diverges, and then the things that you need diverge. That specifically is something that we are going to avoid. The idea isn't, oh, you can reuse your model on the server, and you reuse your templates on the server. The point is it's your app, the same exact app, same code base that you would run in the user's browser just happens to be running on the server. YEHUDA: And I think there's also -- I think there's another important point, which is that if you look at how people do SSR, I think historically people have said, "Well, I'm going to use a view layer that's very good at SSR." And then you would have this pile of hacks that was involved in booting up your app. Honestly, Ember, in the beginning, had piles of hacks used to booting up your app. I definitely remember that period. Now the view layer maybe is very good at running on the client server and, like you said, originally was just like the template. But now maybe the whole view layer is good at it. But now the process of actually booting things is a source of non-determinism. You're saying Zalgo. I'm saying non-determinism. Zalgo is a better word. CHARLES: [Laughter] YEHUDA: And Ember has definitely held off on tackling server side rendering seriously until we felt confident that we had the full stack handled. In other words that, as a framework, we had the whole lifecycle handled. Then actually, if you look at technically what we've been doing recently, a lot of it is like separating out. We have an application right now, an application only -- there's only ever one instance of it. Now we're saying, well, there could be multiple sessions. And so we're really looking at the whole lifecycle of the application and, because we own the whole lifecycle of the application, we can actually feel confident that the path that we're going through is correct, so that's one part of it. The other part of it is essentially what React figured out at a high level. I think what we're doing is equivalent, which is you don't necessarily assume that you got exactly the same thing on the client server because probably in practice there's always going to be some thing or other, like the clock case that Tom talked about, or the hello Yehuda case that I talked about before, the authentication case. What you do is you rerender the template, and you don't say if it's not exactly the same, throw it away and start over. You say parts that are the same you can keep, and parts that are different you replace. Therefore, it's not so much a whack-a-mole problem. It's more like how much replacement can I tolerate and have it not feel janky, right? So you go use it, and if you see that there's an area that's popping in and replacing, that's an area that you have to go and figure out so, first of all, it will work. Right? It will work. It will not be broken. It might feel a little bad, and that's an area for you to go and improve the Zalgoishness of your solution. In practice, in Ember, it will almost always be something weird like you're relying on a non-deterministic DOM API or something like this, or you're relying on some XHR that even though we serialized it, you're getting a push notification, and it's different, and it happens quickly, so it's janked. Right? I think the basic point of try to control everything and also only replace things that are needed will get you to a much better starting place out of the gate with Ember than you will have if you try to do the old solutions. It may turn out to be a lot of work. And if it turns out to be a lot of work regardless, then I think it will still, even with Ember, be a thing that is used by people who really need it and not so much by people who don't. But I'm hopeful that the fact that we own the whole lifecycle of your application will let it be useful for a bigger set of people than people who are desperately in need of it as a solution. BRANDON: Awesome, so I think we're going to wrap up. Is there anything you guys want to give a shout-out to or anyone? YEHUDA: Please sign up for Skylight to make your Rails apps faster. TOM: Yeah, please. Make my Christmas a merry one. YEHUDA: We didn't talk about this at all. TOM: And sign up for Skylight. YEHUDA: We didn't talk about this at all, but Tom and I, much of our day job is working on Skylight. And if you watched my talk at Hack Summit, one of the things that I advocate and I really feel it in my gut because of Skylight is I advocate spending, even if you're full time in open source, spending some time, even a day a week or two days a week, would help a lot working on something that you have to maintain over the long haul because, like I said before, maintenance over the long haul is very difficult for you to market. It's something that you have to feel in your heart. If you're working on an open source project, work on -- use it for a real thing that you spend significant time on that you have to maintain over the long haul so you could feel, in a year, whether you're practice is holding up to being maintainable. And, yes, now that I've talked about Skylight for a second, please sign up. This is how we fund our ability to do any open source. Working on Skylight has definitely been the most enjoyable thing I've done in my career so far in the sense that I've had a lot of control over it, but it's also the most harrowing in the sense that we are responsible for getting all the revenue, so please sign up. BRANDON: All right, well, thanks very much, you all, for coming on. Everybody, go sign up for Skylight. It's very cool, very beautiful, and very actionable insight for Rails apps. Tom, Yehuda, thank you so much for joining us on this. It's been super enlightening. Again, everybody, please go watch Yehuda's talk on keeping the Web Indie. And if you've got a little extra time, the Rails Conf talk on layers of abstraction is also, I found, something that changed my views on a lot of stuff as well. Thanks again, both of you all, for coming on. YEHUDA: Thanks a lot. TOM: Thank you, guys. BRANDON: All right, talk to you later. CHARLES: Thank you, guys.

One of the big buzz phrases circulating at the start of this year's Mobile World Congress in Barcelona, Spain is "wearable tech." Lucy Du with more on what we can expect to hear out of this year's event. Report: The latest generation of smart watches can alert you to messages on your phone and can even scroll through text. Martian watches are among the latest innovations. Stanley Kinsey is the company's president. "Martian watches are about getting notifications and being able to respond to them. We have two different lines of watches. One actually has, this one I'm wearing, has a microphone and speaker on the watch - that you can connect to the voice commands on your smartphone. Android or Apple IOS. So in this case, if I were to get a text message coming in from my phone, it would show up on the watch. I would feel a custom vibration pattern. If it's long, short, long, I know that it's an email. Long, short, short, a text message." Meanwhile Kyocera, a Japanese manufacturer, claims to have produced handsets which can survive a dip in water. Its "Torque" model can survive up to 30 minutes, submerged in water up to one meter deep. Microsoft is also here in Barcelona. It's announced that there'll be an update to its Windows 8 software platform this spring. Microsoft hopes that the update will also improve the launching of applications and the interchange of apps. Away from Microsoft and there's a focus this year on the future of internet-connected gadgets. They're set to talk more and more to home appliances - with mobile devices likely to be at the centre of the conversation. Samsung has scheduled one of its 'unpacked' events. The Galaxy S5 is expected to be on show. Nokia is rumored to have a new Android phone to reveal, with Sony and LG putting up their latest handsets. Elsewhere, ahead of the Mobile World Congress, Mozilla is promoting a new search tool for gadgets with Firefox OS. It's the "adaptive app search" which promises to connect users with content faster and more easily than before. Peter Dolanjksi, a Mozilla spokesman, elaborates on more details. "On the home screen, you can see here I have a search bar. If I type into that search bar, I can type anything I'm looking for, content like U2, the band. So if I type in U2 instead of having to search for music apps and music ticket applications, lyric applications. I just type in the name of the band and immediately I'm presented with relevant mobile applications to me. So Soundcloud, Spotify, Ticketmaster. From there, I can use one of those applications without having to install it. And if I like it, I can add it to my home screen." The adaptive app search function is already available for use.

Are smartphones are getting smarter as the days pass by and some cool features on the horizon are worth talking about. The mobile market is about to be introduced to a new OS - Firefox OS. Mozilla is set to debut their OS this year in international markets.

This week, Kim DotCom is back with Mega, FCC wants gigabit broadband nationwide, Steve Jobs hated poaching, a sneak peek at the new Blackberry OS, Firefox phones, game develper THQ calls it quits, and more Headlines Wikileaks claims Aaron Swartz was an ally and possible source, breaking anonymity Kim DotCom's 'Mega' goes live Mega hits 1 million users after one day FCC pushes for gigabit broadband in all 50 states by 2015 The no-hire paper trail Steve Jobs and Eric Schmidt didn't want you to see Audible Book of the Week Going Clear: Scientology, Hollywood, and the Prison of Belief by Lawrence Wright Musical Interlude: Tom Cruise Crazy by Jonathan Coulton More Headlines Mozilla debuts two Firefox OS developer preview phones BlackBerry 10 exposed in full detail thanks to leaked screenshots The end of THQ Why this jilted Kickstarter backer decided to sue — & why he was right Subscribe! The Drill Down on iTunes (Subscribe now!) Add us on Stitcher! The Drill Down on Facebook The Drill Down on Twitter Geeks Of Doom's The Drill Down is a roundtable-style audio podcast where we discuss the most important issues of the week, in tech and on the web and how they affect us all. Hosts are Geeks of Doom contributor Andrew Sorcini (Mr. BabyMan), VentureBeat editor Devindra Hardawar, marketing research analyst Dwayne De Freitas, and Startup Digest CTO Christopher Burnor. Occasionally joining them is Box tech consultant Tosin Onafowokan.

Why Microsoft losing money is good news, the size of Mayer's package, Firefox OS on your desktop, and more. Hosts: Tom Merritt, Sarah Lane, Iyaz Akhtar, and Jason Howell Guest: Darren Kitchen Download or subscribe to this show at https://twit.tv/shows/tech-news-today. Submit and vote on story coverage at technewstoday.reddit.com. We invite you to read, add to, and amend our show notes at wiki.twit.tv. Thanks to CacheFly for the bandwidth for this show. Sponsor: Squarespace, promo code: TNT7

Why Microsoft losing money is good news, the size of Mayer's package, Firefox OS on your desktop, and more. Hosts: Tom Merritt, Sarah Lane, Iyaz Akhtar, and Jason Howell Guest: Darren Kitchen Download or subscribe to this show at https://twit.tv/shows/tech-news-today. Submit and vote on story coverage at technewstoday.reddit.com. We invite you to read, add to, and amend our show notes at wiki.twit.tv. Thanks to CacheFly for the bandwidth for this show. Sponsor: Squarespace, promo code: TNT7