Jump to content

Search the Community

Showing results for tags 'developers'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Site Related
    • News & Updates
    • Site / Forum Feedback
    • Member Introduction
  • News
    • General News
    • FileSharing News
    • Mobile News
    • Software News
    • Security & Privacy News
    • Technology News
  • Downloads
    • nsane.down
  • General Discussions & Support
    • Filesharing Chat
    • Security & Privacy Center
    • Software Chat
    • Mobile Mania
    • Technology Talk
    • Entertainment Exchange
    • Guides & Tutorials
  • Off-Topic Chat
    • The Chat Bar
    • Jokes & Funny Stuff
    • Polling Station

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...

Found 17 results

  1. Any love for Linux, Mac, iOS, Android, WebAssembly? Bueller? Bueller? Microsoft's roadmap for developing Windows applications is opposed by some programmers who want to see a cross-platform solution, rather than just being Windows-only. Spanish developer José Nieto this week raised an issue on GitHub, stating that WinUI, which Microsoft is positioning as “the native UI platform for Windows 10,” should target not only Windows, but also Linux, Mac, iOS, Android and WebAssembly – this last so it would also run in a web browser. This would go against the normal pattern, where a native UI platform is able to take advantage of all the features of the operating system, fits in seamlessly with its look and feel, and is optimized for performance. Supporting cross-platform is a burden that requires compromises. The "conceptual overview" for WinUI, which Microsoft says is the native UI framework for Windows 10 The situation with Windows is unusual though. The look and feel of the operating system is less consistent than it should be, thanks to lots of legacy along with the dual personality deliberately introduced for Windows 8. The modern app platform introduced for Windows 8 evolved into the Universal Windows Platform (UWP). Even in Windows 7 days, the UI was messy. Windows Presentation Foundation (WPF) was the new thing and renders using DirectX graphics, while the old Win32 API does not. While Microsoft calls WinUI the native UI in one document, in another it says that the Win32 API is “the original platform for native C/C++ Windows applications that require direct access to Windows and hardware,” and says it is “the platform of choice for applications that need the highest level of performance and direct access to system hardware.” The Fluent Design System which Microsoft is promoting to WinUI developers is itself cross-platform, described as “natural on every device,” with examples for Web, Windows, iOS and Android. Considering all these factors, perhaps the idea of a cross-platform WinUI is not so unreasonable. Nieto is an enthusiast for XAML, the XML-based presentation language used in different guises by various Microsoft frameworks. If Avalonia can use XAML for cross-platform GUI applications, why not Microsoft? The ensuing discussion is illuminating, in terms of why Microsoft has lost the loyalty of some of its developers. WPF was well liked for its power and flexibility, but UWP has not been a satisfactory replacement. “It’s not universal,” says Nieto, since the death of Windows mobile “truncated the One Windows vision.” Sandbox restrictions make it unsuitable for advanced applications, the role of the Microsoft Store is troublesome, and third-party controls are lacking, he said. Microsoft does in fact address many of these issues in WinUI, which can use the Win32 app model as well as UWP. It also has an advantage over WPF in that it easily supports languages other than C# and Visual Basic. WinUI itself is written in C++. WinUI is also, according to Microsoft, ideal as a “native Windows target for web and cross-platform frameworks,” an example being React Native. Canadian developer Mario Pintaric says that UWP is fine for everything other than “kernel level tooling,” arguing that “you have a much better user experience from multiple perspectives (security, ease of deployment, install/uninstall experience, etc). The security sandbox of UWP is an important (essential) feature. In many respects UWP is now well ahead of WPF.” Pintaric acknowledges though that Microsoft made errors with UWP, both in quality and in failing to meet the requirements of line-of-business (LOB) applications in areas like a Data Grid, and validation states for form applications. “Most of these have been addressed but it took too long,” he said, concluding that “I completely agree that developers have lost hope Microsoft will do the right thing.” Perhaps the most telling criticism comes from another developer who observes that UWP was really designed for mobile and touch control. “Most developers use UWP to develop Desktop apps, and the UI does not match that,” he said, giving examples for various controls like scroll bars and radio buttons. “The biggest problem is that things that should take 10 minutes, usually take two hours or more,” he said. How can Microsoft win back developer loyalty? The company has excellent developer tools in Visual Studio and Visual Studio Code, but the range of choices if you sit down to code a GUI application for Windows remains bewildering. It will take more than a few statements to convince developers that WinUI really is the future. A strong launch for Windows 10X, Microsoft's latest go at a modernised Windows, would help. In the meantime, developers fall back on another, and more welcome, feature of Windows: that applications built with old and enduring technology like Win32 and WPF still run fine. Source
  2. And 2 in 5 programmers gripe they are underpaid The Go programming language tops the list of skills that software developers say they'll learn next, according to a survey of 116,000 programmers conducted by hiring biz HackerRank. Some 36.2 per cent of respondents expressed interest in the Google-backed language, which is suitable for systems programming for those reconciled to the potential performance impact of built-in garbage collection. Python came next on the planned study list, with 27.7 per cent looking to enjoy the chaos of the language's package management ecosystem, followed by Kotlin, a more approachable, less litigation-prone Java, at 24.9 per cent. Typescript, JavaScript's more responsible younger sibling, finished fourth in the beauty contest, at 20.7 percent. In its wake came R (20 per cent), Scala (18.7 per cent), Swift (16.7 per cent), Rust (16.3 per cent), Ruby (15.9 per cent), and JavaScript (15 per cent) – which happens to be the most widely known language. JavaScript, for all its bad parts, is the language skill corporate hiring managers most look for (53.6 per cent) when recruiting, according to the survey. That's followed by Python (49.5 per cent), Java (44.1 per cent), C# (19.7 per cent), C++ (18.3 per cent), PHP (17 per cent), no preference (14.3 per cent), C (11.5 per cent), Go (11 per cent), and Ruby (7.9 per cent). The most common role companies are looking to fill is full-stack developer, followed by back-end developer, and data scientist. Among coders looking to maximize compensation, it's not JavaScript that pays the most. That honor goes to Perl. According to the survey, Perl devs earn 54 per cent more than the average developer, which perhaps explains why it was deemed the most hated programming language a few years ago. Scala (+42 per cent above salary average) and Go (+33 per cent above salary average) also appear to pad one's paycheck. HackerRank speculates that the higher salary average correlates with developer seniority, since about 10 per cent of senior developers know Perl, beloved by El Reg, while only about two per cent of developers do. Nearly one in three hiring managers (32 per cent) have brought in coding bootcamp graduates and most (72 per cent) found bootcampers to be at least as well equipped for the job as other hires. It has been suggested that the buggy app produced for the recent Iowa Democratic Caucus came from inexperienced developers. Make of that what you will. Also, self-taught programmers may be heartened to learn that 32 per cent of developers who work for companies of 49 people or less do not have a college degree. That figure is only 9 per cent among companies with more than 10,000 employees. In the US, the highest paying metro areas in terms of average salary for developers are San Francisco ($147,947.71), Seattle ($134,538.52), Los Angeles ($129,079.97), Boston ($116,803.62), and New York City ($115,792.24). New York City is the most expensive US city in recent cost-of-living figures, with San Francisco coming in third behind Honolulu. US developers make more on average ($109,167.36) than anywhere else in the world. Next on the list are Australia ($88,538.51), Canada ($72,771.32), Netherlands($68,194.06), and the UK ($65,387.57). If you ask developers around the world whether they're being paid fairly, only 35 per cent believe so. About 39 per cent contend they're not being paid what they're worth. And 26 per cent aren't sure. Perhaps the most distressing stat put forth in the survey is a look at how developers spend their leisure time. Asked what they do to take a break from coding, 2.8 per cent said they never take a break from coding. The Register hopes this represents the percentage of people who amuse themselves by deliberately submitting false data to surveys. The full 2020 Developer Skills Report can be found on the HackerRank website. Source
  3. At least 11 accessed data in the last two months Facebook says that even after it locked down its Groups system last year, some app developers retained improper access to information about members. A company blog post reports that roughly 100 developers might have accessed user information since Facebook changed its rules in April of 2018, and at least 11 accessed member data in the last 60 days. It says it’s now cut all partners off from that data. Facebook Group administrators can use third-party tools to manage their groups, giving apps information about its activity. Since the changes last year, developers shouldn’t be able to see individual members’ names, profile pictures, or unspecified other profile data. Facebook platform partnerships head Konstantinos Papamiltiadis says a recent security review found that some apps still had access, however. Papamiltiadis says there’s no evidence that partners have abused their access, but he says Facebook has asked them to delete any improperly obtained information and will conduct audits to confirm it’s gone. Facebook didn’t disclose the names of these roughly 100 developers. Papamiltiadis only says that the apps were “primarily social media management and video streaming apps, designed to make it easier for group admins to manage their groups more effectively and help members share videos to their groups.” We also don’t know exactly what information was involved besides names and photos, nor how many users and groups the apps served. Facebook locked down the Groups application programming interface (API) as part of a general crackdown after the Cambridge Analytica data-sharing scandal. It added rules that required developers to get approval from Facebook before using the Groups API, then relaunched the system with new features in July, suggesting that it was trying to implement real oversight — so it’s a little surprising that these apps slipped through the cracks. Source: Facebook says 100 developers might have improperly accessed Groups member data (via The Verge)
  4. Last week at the Android Dev Summit, Google announced a feature that Chrome OS enthusiasts have wanted for years: the ability to sideload Android apps without enabling Developer Mode. We’ve seen code commits in the past that would have enabled this feature, but none of those implementations ever made their way to the stable channel. Now that Google has officially confirmed this feature will arrive in Chrome OS 80, which is set for a stable release in the second week of February 2020, we no longer need to religiously monitor the Chromium Gerrit for this feature addition. As you can see in the featured image above, retrieved via AboutChromebooks, Google is adding this feature to let Android app developers deploy their apps straight from Android Studio. With a 22% growth in year-on-year Chromebook sales (from September of 2018 to August of 2019) and the total amount of time spent on Android apps on Chrome OS grown by a factor of 4, Android app developers are incentivized to bring their work to Chromebooks. Developing for Chromebooks requires considerations like how your app reacts to changes in display modes (laptop and tablet), window management (multi-window and free-form windows), and keyboard/mouse input, so it’s recommended to test your app on native hardware. To that end, Google pushed to make Chrome OS more developer-friendly by adding a Linux container last year, enabling the ability to run the Linux version of Android Studio. While you can develop and build Android apps on a Chromebook, deploying the app is a bit of a headache. Currently, the recommended way to sideload an Android app on Chrome OS is to enable Developer Mode. With Developer Mode enabled, sideloading an Android app is as simple as clicking on your compiled APK file. However, Developer Mode is inherently insecure as it relaxes verified boot protections and grants access to a root shell. It’s also a pain to deal with since it requires powerwashing (factory resetting) your device and dealing with an annoying warning screen that you have to manually bypass on every boot. Thankfully, when Chrome OS 80 rolls out in the stable channel in February 2020, all developers will be able to deploy their Android apps straight from Android Studio onto their Chromebook, without having to enable Developer Mode. If you’re on the Chrome OS Dev channel, you’ll be able to test this out as early as late next month. Unfortunately, it doesn’t look like Google intends for this feature to be used by end-users. According to the commit that likely implements this feature, this feature requires Crostini (Linux app support) to be enabled, limiting which Chromebooks will have access to the feature. Furthermore, disabling the feature requires a powerwash. If you’re comfortable with the command line, though, sideloading Android apps should be as simple as using “adb install.” Alternatively, you could just “adb push” the APK, enter “adb shell,” and then use “pm install,” right now. Source: Google says Chrome OS 80 will bring easier Android app sideloading for developers (via XDA Developers) p/s: While this news is also about Android app sideloading, but this article is best suited to be placed under Software News as the main post talks about Chrome OS which is installed on laptops (and even CPU's as well).
  5. Last year, Apple Inc. software chief Craig Federighi said developers would be able to easily bring their iPad apps to Mac computers, essentially letting coders write an app once and deploy it across millions more devices. So far, the reality has fallen short for some developers and is even leaving consumers paying twice for apps. Major app developers and service providers like Netflix Inc. are also demurring on taking part, at least at this early stage. Apple rolled out Catalyst, the technology to transition iPad apps into Mac versions, on Monday. It’s the initial step toward a bigger goal: By 2021, developers should be able to build an app once and have it work on iPhones, iPads and Mac computers through a single, unified App Store. But the first iteration, which appears to still be quite raw and in a number of ways frustrating to developers, risks upsetting users who may have to pay again when they download the Mac version of an iPad app they’ve already bought. “As a user, I don't want to pay again just to have the same app,” said longtime Apple developer Steven Troughton-Smith. “As a developer, I don't want my users to have to make that decision.” James Thomson has had to work harder than he expected to get his popular PCalc calculator iPad app running well on Mac computers. Getting paid a second time for that extra work makes sense for developers, but consumers may not immediately understand that after Apple made the porting process sound as easy as checking a box, he said. Kevin Reutter, who has brought his Planny app to Mac computers, called the situation “sad.” These teething problems are a risk for Apple, which relies on a legion of outside developers to maintain, improve and enhance its world-leading app ecosystem and make its devices useful and unique. The unified App Store project, long known as Marzipan internally, promises to save developers time while spurring the creation of new software. It’s a key part of Apple’s push to generate more revenue from services -- although having customers pay twice is highly unlikely to be part of the long-term plan. Most consumer-facing software platforms don’t have the double-charging problem. Google’s Play Store runs on Android and Chromebook devices, sharing purchases across them. Likewise, Facebook, with its Oculus app strategy, avoids charging customers twice for the same app across its Go and Quest headsets. Apple itself is a proponent of iOS apps that users purchase once and can use across the iPhone, iPad, Apple TV and Apple Watch. An Apple spokesman declined to comment. The company says a number of iPad apps are launching on the Mac this week, with more coming in the near future. Current titles include Rosetta Stone and Money Coach with Twitter and others coming later. However, Netflix Inc., the largest U.S. video-streaming service with the second most popular free iPad app, said on Tuesday that it won’t be taking part. On day one of Apple’s new technology debut, the Mac App Store showed only about 20 compatible iPad apps, out of a possible library of more than a million iPad-optimized applications. Catalyst is the “future of Mac app development,” said Troughton-Smith, who’s anxious for Apple to iron out the rough edges. “This will determine whether it's a great future or a mediocre future for the Mac.” Other developers said the technology is a useful bridge for those who’ve never developed for the Mac before and are only familiar with the iPhone and iPad platforms. Developers have found several problems with Apple’s tools for bringing iPad apps over to Mac computers. Some features that only make sense on iPad touchscreens, such as scrollable lists that help users select dates and times on calendars, are showing up on the Mac, where the input paradigm is still built around a keyboard and mouse or trackpad. Troughton-Smith said Mac versions of some apps can’t hide the mouse cursor while video is playing. He’s also found problems with video recording and two-finger scrolling in some cases, along with issues with using the keyboard and full-screen mode in video games. Thomson, the PCalc developer, said some older Mac computers struggle to handle Catalyst apps that use another Apple system called SceneKit for 3-D gaming and animations. Source
  6. If you use GitHub's online services in a country facing US sanctions, you could be about to be kicked off all but the most basic offerings. There's a debate over free speech taking place after Microsoft-owned GitHub "restricted" the account of a developer based in the Crimea region of Ukraine, who used the service to host his website and gaming software. GitHub this week told Anatoliy Kashkin, a 21-year-old Russian citizen who lives in Crimea, that it had "restricted" his GitHub account "due to US trade controls". Kashkin uses GitHub to host his website and GameHub, a launcher for Linux systems that combines games from Steam, GOG, and Humble Bundle in a single user interface. Kashkin says GitHub advised him this week that it had restricted his account, pointing to its page about US trade controls, which lists Crimea, Cuba, Iran, North Korea, and Syria as countries facing US sanctions. As the developer reports, his website https://tkashkin.tk, which is hosted on GitHub, now returns a 404 error. He also can't create new private GitHub repositories or access them. While his website could easily be moved to another hosting provider, the block does pose a challenge for his work on GameHub, which has an established audience on GitHub. "GitHub has many useful features and it's safe to assume that many of people interested in GameHub already use GitHub," wrote Kashkin. "Discoverability is also a very important factor. I don't think many people will find GameHub on a self-hosted server somewhere and I don't think many of them will report issues there either," he added. Fellow GitHub users have suggested he use other hosting services, such as GitLab or Atlassian, which runs the BitBucket Git service. However, the former is headquartered in the US while the latter was founded in Australia but also listed on the US NASDAQ exchange in 2015, meaning both likely would need to comply with the same trade sanctions. GitHub does offer developers an appeal form to dispute restrictions but Kashkin told ZDNet that, at this point, there's nothing to gain by appealing the restriction. "It is just pointless. My account is flagged as restricted and, in order to unflag it, I have to provide a proof that I don't live in Crimea. I am in fact a Russian citizen with Crimean registration, I am physically in Crimea, and I am living in Crimea my entire life," he said. For developers in Kashkin's position, GitHub's wording of its restrictions isn't exactly helpful either. "For individual users, who are not otherwise restricted by U.S. economic sanctions, GitHub currently offers limited restricted services to users in these countries and territories. This includes limited access to GitHub public repository services for personal communications only," it says. As GitHub notes on its page about US trade controls, US sanctions apply to its online hosting service, GitHub.com, but its paid-for on-premise software -- aimed at enterprise users -- may be an option for users in those circumstances. It also claims to be in discussions with US regulators about how to rectify the situation. "Users are responsible for ensuring that the content they develop and share on GitHub.com complies with the U.S. export control laws, including the EAR (Export Administration Regulations) and the US International Traffic in Arms Regulations (ITAR)," GitHub says. "The cloud-hosted service offering available at Github.com has not been designed to host data subject to the ITAR and does not currently offer the ability to restrict repository access by country. If you are looking to collaborate on ITAR- or other export-controlled data, we recommend you consider GitHub Enterprise Server, GitHub's on-premises offering." Kashkin isn't the only developer from a US-sanctioned nation who's recently faced troubles on GitHub. He told ZDNet that friends in Crimea have recently faced similar sanction-related restrictions. GitHub is also imposing restrictions in Iran. Hamed Saeedi, a developer based in Iran, posted a complaint on Medium claiming that "GitHub blocked my account and they think I'm developing nuclear weapons". The developer claims to have been using GitHub since 2012 and says he recently received an email from GitHub about trade controls, much like Kashkin. He also says that GitHub blocked all Iranian accounts. "Due to U.S. trade control law restrictions, your GitHub account has been restricted," it advised him. "For individual accounts, you may have limited access to free GitHub public repository services for personal communications only," it continued, guiding him to the GitHub trade controls page and a link to the appeals page. Source
  7. I have been a bit critical of Linux Mint in the past, but the truth is, it is a great distribution that many people enjoy. While Mint is not my favorite desktop distro (that would be Fedora), I recognize its quality. Is it perfect? No, there is no such thing as a flawless Linux-based operating system. Today should be happy times for the Linux Mint community, as we finally learn some new details about the upcoming version 19.2! It will be based on Ubuntu 18.04 and once again feature three desktop environments -- Xfce, Mate, and Cinnamon. We even found out the code name for Linux Mint 19.2 -- "Tina." And yet, it is hard to celebrate. Why? Because the developers seem to be depressed and defeated. They even appear to be a bit disenchanted with Free Software development overall. Clement Lefebvre, leader of the Linux Mint project, shared a very lengthy blog post today, and it really made me sad. You can read part of it below. And no, this sad tone is not an April Fool's prank, sadly. It’s not always easy to achieve what we want, sometimes it’s not even easy to define what we want to achieve. We can have doubts, we can work really hard on something for a while and then question it so much, we’re not even sure we’ll ship it. We can get demotivated, uncertain, depressed even by negative reactions or interactions, and it can lead to developers stepping away from the project, taking a break or even leaving for good. And then sometimes simply seeing people enjoy what we did can boost an entire team, whether it’s seeing happiness in an email/comment or getting a feeling of satisfaction after a constructive interaction which leads to a fix or an implementation. I personally haven’t enjoyed this development cycle so far. 2 of our most talented developers have been away. Boosting performance in the Muffin window manager hasn’t been, and still isn’t, straight forward. Feedback on the new website and logo brought a huge amount of incertitude. We’ll still have a great release in the end and we’ll still achieve plenty of improvements (we did already to a certain extent), but we need to be strong and remain confident and it’s not easy when so much time is invested into something and then a month later it’s not ready, or it causes other issues, or it might please some people but not others. Lefebvre continues... For a team to work, developers need to feel like heroes. They want the same things as users, they are users, they were “only” users to start with. At some stage they decide to get involved and they start investing time, efforts and emotions into improving our project. What they’re looking for the most is support and happiness. They need feedback and information to understand bugs or feature requests and when they’re done implementing something, they need to feel like heroes, they literally do, that’s part of the reason they’re here really. I can show them 500 people donated money last month, I can forward emails to the team where people tell me how much they love Linux Mint, I can tell them they’re making a difference but there’s nothing like interacting directly with a happy user, seeing first-hand somebody be delighted with what you worked on. How our community interacts with our developers is key, to their work, to their happiness and to their motivation. Clem quite literally says he is not enjoying the Linux Mint development nowadays, which really breaks my heart. Look, developing a free operating system and largely depending on donations to keep the project going is obviously stressful -- I imagine it is hard to ever feel truly secure. With that said, once you lose your passion and joy, there is the possibility the project could suffer. He also expresses surprise and sadness at all the negativity surrounding the upcoming website and logo redesigns. I thought the redesigns were very boring and uninspired, and I was vocal about that. Now I feel awful about contributing to the development team’s feelings of gloom -- my opinions were sincere, however. Even worse, Clem shares that there is some tension between the team members, particularly regarding Cinnamon and its Muffin window manager. He provides the following details. It’s all about Muffin at the moment. We’re trying to make it smoother, to make the windows feel lighter… radical changes and refactoring occurred, it’s eating a lot of time and we’re chasing regressions left, right and center. This is documented at https://github.com/linuxmint/cinnamon/issues/8454. It’s a really tough exercise, it creates tensions within the team but the potential is there, if we can make our WM snappier it’s worth the hassle. Do I think the Linux Mint operating system is in trouble? No, that would be way premature. Still, I am worried that this very public display could be foreshadowing some negativity and roadbumps in the future. I hope I am wrong, as it would be a sad world without Linux Mint. So, what can be done? Well, if you love Linux Mint and you want the developers to be satisfied and joyful, why not make a donation? You can do so in many ways here. Even if you don't use Linux Mint, you should donate to show support for both the Linux and Open Source communities. You can send the message that Free Software development has a bright future. Money aside, I urge you to also Tweet to the Linux Mint team here. Tell them how much they mean to you, and how the operating system improves your life. Make them feel like heroes. [UPDATE 4/2/2019] Unfortunately, it seems my concerns about the Linux Mint developers were quite correct. On Reddit, in response to this very article, Jason Hicks (jaszhix), Muffin maintainer and member of the Linux Mint team, says the following. I'll just say this much as far as Muffin is concerned, I'm the main maintainer of it this cycle. People are testing it. Major refactoring occurred. Windows you can't see no longer sit in the background wasting CPU time in the compositor, painting. A lot of mutter commits refactored in, and a lot of my own. The code changed is a lot, so it's expected for there to be some regressions. I also have a life outside open source work, too. It's not mentally sound to put the hours I've put into the compositor. I was only able to do what I could because I was unemployed in January. Now I'm working a job full time, and trying to keep up with bug fixes. I've been spending every night and weekend, basically every spare moment of my free time trying to fix things. There's also been tension because we're 1-2 months from a release. We've had contentious debate about input latency, effects of certain patches, and ways to measure all of this. Other team members are going through their own equally hard circumstances, and it's an unfortunate amount of stress to occur all at once at the wrong times. We're human at the end of the day. I wish these aspects didn't leak into the blog post so much, so just wanted to vent and provide some context. If you take away anything from it, please try the PPA and report bugs. We need people looking for things that might get stuck in cinnamon 4.2. Yikes. This is not a happy developer. To make things even worse, Hicks is apparently embarrassed by the official Linux Mint blog post! Another Reddit member named tuxkrusader responds to Hicks by saying "I'm slightly concerned that you're not a member of the linuxmint group on github anymore. I hope you're not on bad terms with the project." Hicks shockingly responds by saying "Nope, I hid my project affiliation because that blog post makes me look bad." Wow. Hiding his affiliation with the Linux Mint project on GitHub? It seems things may be worse than I originally thought... Source
  8. Top developers behind ad-blocking and anti-tracking browser extensions say they’re alarmed by potential changes coming to Chrome recently disclosed in a public Google document. As a result, at least one company is now threatening possible legal action. The proposed design changes would replace the API relied upon by privacy extensions like uBlock and Ghostery with another designed to “diminish the effectiveness of content blocking and ad blocking extensions,” the Register reported on Tuesday. The proposal would leave functional basic filters employed by Adblock Plus, which, the site noted, Google has reportedly paid to whitelist its own ads. Extension developers say, among other potential consequences, the changes would kill competition among third-party ad blockers by placing new limits on their sophistication, ultimately making it harder to adequately shield Chrome users from undesired online tracking. “This would basically mean that Google is destroying ad blocking and privacy protection as we know it,” Ghostery said in a statement. “They pretend to do this for the sake of privacy and browser performance, however in reality, users would be left with only very limited ways to prevent third parties from intercepting their surfing behavior or to get rid of unwanted content.” Saying the change would exemplify a “misuse” of Google’s “market-dominating position,” Ghostery added that it would “consider filing an anti-trust complaint” if Google followed through. Here’s how Ghostery described the proposal: Initially telling reporters that its proposal is merely “subject to change,” Google signaled more strongly on Wednesday that it was preparing to rein in its plans. “We want to make sure all fundamental use cases are still possible with these changes and are working with extension developers to make sure their extensions continue to work,” a Google spokesperson told Gizmodo. The Register reported on related concerns raised by Raymond Hill, lead developer of uBlock Origin—a content-blocking extension with more than 10 million active Chrome users—who said his privacy software would “no longer be able to exist” if Google implemented the proposal described in the public document. Hill added that the changes would likewise break uMatrix, a more advanced extension with granular controls for allowing users to block connections and content by data type. Hill and other developers were seen discussing the matter on Chromium bug tracker, though a Google software engineer locked the thread on Tuesday after deleting several related comments. “I am another ad blocker developer (AdGuard), and from our perspective, the proposed change will be even more crippling to all ad blockers than what was done by Apple when they introduced their declarative content blocking API,” reads one of those undeleted comments. Source
  9. What do Heartbleed, WannaCry, and million dollar iPhone bugs have in common? Alex is a software security engineer at Mozilla, where he works on sandboxing and anti-exploitation for Firefox. Previously he was a software engineer with the United States Digital Service, and served as a member of the board of directors of both the Python and Django Software Foundations. One bug affects iPhones, another affects Windows, and the third affects servers running Linux. At first glance these might seem unrelated, but in reality all three were made possible because the software that was being exploited was written in programming languages which allow a category of errors called "memory unsafety." By allowing these types of vulnerabilities, languages such as C and C++ have facilitated a nearly unending stream of critical computer security vulnerabilities for years. Imagine you had a program with a list of 10 numbers. What should happen if you asked the list for its 11th element? Most of us would say an error of some sort should occur, and in a memory safe programming language (for example, Python or Java) that's what would happen. In a memory unsafe programming language, it'll look at wherever in memory the 11th element would be (if it existed) and try to access it. Sometimes this will result in a crash, but in many cases you get whatever happens to be at that location in memory, even if that portion of memory has nothing to do with our list. This type of vulnerability is called a “buffer-overflow,” and it's one of the most common types of memory unsafety vulnerabilities. HeartBleed, which impacted 17 percent of the secure web servers on the internet, was a buffer-overflow exploit, letting you read 60 kilobytes past the end of a list, including passwords and other users’ data. There are other types of memory unsafety vulnerabilities with C/C++, though. Other examples are “type confusion,” (mixing up what type of value exists at a place in memory) “use after free,” (using a piece of memory after you told the operating system you were done with it) and “use of uninitialized memory” (using a piece of memory before you’ve stored anything in it). Together, these form some of the most common vulnerabilities across widely used software such as Firefox, Chrome, Windows, Android, and iOS. I've been tracking the security advisories for these projects for more than a year and in almost every release for these products, more than half of the vulnerabilities are memory unsafety. More disturbingly, the high and critical severity vulnerabilities (generally those which can result in remote code execution, where an attacker can run any code they want on your computer; this is usually the most severe type of vulnerability) are almost always memory unsafety. From my own security research into the widely used open source image processing libraries ImageMagick and GraphicsMagic, in the last year I've found more than 400 memory unsafety vulnerabilities. If these vulnerabilities are so prevalent, can cause so much damage, and there are languages that don't have these pitfalls, then why are these languages still so common? First, while there are now good choices for languages that prevent memory unsafety vulnerabilities, this wasn’t always the case. C and C++ are decades-old and enormously popular languages, while memory-safe languages that are usable for low-level programming like web browsers and operating systems, such as Rust and Swift, are only just starting to achieve popularity. A bigger issue is that when developers sit down to choose a programming language for a new project, they're generally making their decision based on what languages their team knows, performance, and ecosystem of libraries that can be leveraged. Security is almost never a core consideration. This means languages which emphasize security, at the cost of ease of use, are at a disadvantage. Furthermore, many of the most important software projects for internet security are not new, they were started a decade or more ago, for example Linux, OpenSSL, and the Apache webserver are all more than twenty years old. For massive projects like these, simply rewriting everything in a new language isn't an option; they need to be incrementally migrated. This means that projects will need to be written in two languages, instead of one, which increases complexity. It can also mean needing to retrain a huge team, which takes time and money. Finally, the largest problem is that many developers don't believe there's a problem at all. Many software engineers believe the problem is not that languages like C/C++ facilitate these vulnerabilities, it's that other engineers write buggy code. According to this theory, the problem isn't that trying to get the 11th item in a 10 item list can result in a critical vulnerability, the problem is that someone wrote code which tries to get the 11th item in the first place, that they either weren't a good enough engineer or weren't disciplined enough. In other words, some people think that the problem isn't with the programming language itself, only that some people don't know how to use it well. Many developers find this position compelling, despite the mountain of competing evidence—these vulnerabilities are omnipresent, and effect even companies with the largest security budgets and the most talented developers! It's one thing to discuss the tradeoffs and how we can make memory-safe languages easier to learn, but after thousands upon thousands of vulnerabilities that are preventable with a better programming language, the evidence makes it clear that "try harder not to have bugs" is not a viable strategy. However, there is some good news. Not everyone is in denial about this problem. Rust (disclosure: Rust’s primary sponsor is my employer, Mozilla) is a relatively new programming language which aims to be usable for every problem C and C++ are used for, while being memory safe and thus avoiding these security pitfalls. Rust is gaining adoption, it’s now used by Mozilla, Google, Dropbox, and Facebook, and I believe this demonstrates that many people are starting to look for systemic solutions to the memory unsafety problem. Further, Apple’s Swift programming language is also memory safe, while its predecessor, Objective-C, was not. There are a number of things we can do to accelerate the search for a comprehensive solution to the ongoing security disaster that is memory unsafety. First, we can get better at quantifying how much damage memory safety causes. While I've been performing rudimentary statistics for a few projects, there is an opportunity for more rigorous tracking. The CVE project, an industry-wide database of known vulnerabilities, could track for every vulnerability whether it was a memory unsafety issue, and whether a memory safe language would have prevented it. This will help us answer questions like, "Which projects would benefit most from a programming language that is memory safe?" Second, we should invest in research into how to best migrate existing large software projects to memory safe languages. Currently the idea of migrating something like the Linux kernel to a different programming language is a task almost too large to imagine. Dedicated research into what sort of tools could facilitate this, or how programming languages could be designed to make it easier, would dramatically reduce the cost of improving older, larger, projects. Finally, we can shift the culture around security within software engineering. When I first learned C++ in college, it was expected that sometimes your program would crash. No one ever told me that many of those crashes were also potential security vulnerabilities. A lack of awareness about the connection between the bugs and crashes developers encounter and security issues, from early on in a developer’s career, is emblematic of how security is a secondary concern in software engineering and how we teach it. When creating new projects it should be accepted that one of the criteria when choosing a programming language should be "How will this choice impact security?" Memory unsafety is currently a scourge for our industry. But it doesn't have to be the case that every Windows or Firefox release fixes dozens of avoidable security vulnerabilities. We need to shift ourselves from treating each memory unsafety vulnerability as an isolated incident, and instead treat them as the deeply rooted systemic problem they are. And then we need to invest in engineering research into how we can build better tools to solve this problem. If we make that change and that investment we can make a dramatic improvement to computer security for all users, and make HeartBleed, WannaCry, and million dollar iPhone bugs far less common. Source
  10. Above: Even amongst Mac App Store developers, the overall impression of the store remains negative. Apple thoroughly revamped the look and feel of the Mac App Store this year, debuting “editorial” recommendations and an iOS-inspired interface for its macOS software storefront. But a new survey from CleanMyMac developer MacPaw suggests developers remain unimpressed by the App Store due to a series of well-established problems that haven’t been addressed, and that Apple is “slowly losing devs to the great unknown” — other distribution options — as a result. MacPaw’s survey is in its third year and with 814 responses has a pretty robust collection of participating developers. The company saw a slight decline in the number of Mac App Store exclusive developers, falling from 23 to 22 percent, and a similarly small uptick in developers distributing outside the store, 32 versus 30 percent. It also noted a 3 percent increase in the proportion of revenues coming from sales outside the Mac App Store. The real issues, however, become apparent in developer responses to questions about Mac App Store satisfaction. Forty percent of MAS-using developers are “detractors,” with 37 percent “passives,” and 22 percent “promoters,” numbers that only look good compared with even worse scores in the prior year. In three survey years, the store’s promoters number peaked at 23 percent, which is to say that three out of four developers participating in the store aren’t enthusiastic about it. Unsurprisingly, Apple’s numbers are even worse amongst developers who aren’t selling through the Mac App Store. As of 2018, 84 percent of that group are detractors, versus 9 percent passives and 7 percent promoters. Those numbers are modestly improved from prior years’ results, but the takeaway is fairly clear: Most developers who participate don’t love the store, and those who don’t participate seem to hate it. Digging into survey answers, the biggest issues developers still have are ones that have been identified multiple times over the years: inability to offer trials or priced upgrades, as well as a lack of analytics. Lengthy app reviews and sandboxing rules have been issues for some developers, as well. Though the former has seen marked improvement in 2018, 33 percent of MAS developers still rate “faster approval” as a desired improvement, and 65 percent of non-MAS developers cite the approval process as a reason for staying out. Above: The 2018 redesign of the Mac App Store. One thing developers seem to be less concerned about at this point is Apple’s 30 percent cut of revenues. The number of dissatisfied developers is 49 percent — down a sharp 20 percent from a year ago — and 63 percent of developers say they make more money from Apple than non-Apple stores. Fifty-eight percent of developers who aren’t already making non-Apple software wouldn’t even consider doing so. While MacPaw’s survey also includes details on its Mac App Store alternative, Setapp, the report is transparent about developer satisfaction and dissatisfaction with both solutions; it also goes into detail regarding developers’ positive and negative experiences with switching to subscription models, as well as their readiness for Apple’s upcoming Marzipan iOS/macOS development initiative — 60 percent of Mac developers say they aren’t yet ready. The full survey is worth seeing and is available here. Source
  11. Linux Mint is one of the most popular Linux-based desktop operating systems for a reason -- it’s really good. By leveraging the excellent Ubuntu for its base, and offering a top-notch user experience, success is pretty much a guarantee. While the distribution primarily focuses on two desktop environments -- Mate and Cinnamon -- the latter is really the star of the show. Cinnamon is great because it uses a classic WIMP interface that users love, while also feeling modern. With Cinnamon 3.8, the Linux Mint Team focused on improving the DE's performance, and today, the team shares that it is continuing that mission with the upcoming 4.0. In particular, the team is focusing on Vsync. Clement Lefebvre, Project Leader, Linux Mint shares the following in a new blog post. I must say, it is refreshing that the Linux Mint Team is focusing on performance and "under the hood" improvements for Cinnamon 4.0. Quite frankly, the desktop environment is already quite feature complete and a joy to use. No, I am not saying the interface is perfect and the superficial should be ignored, but for now, it shouldn't be a priority. The developers are absolutely on the right track with Cinnamon 4.0. Source
  12. Will make its phones far less desirable for developers CHINESE PHONE GIANT Huawei has ended support for bootloaders on its devices. The company admitted the news in a statement sent to Android Authority after the dedicated support page for the process disappeared without any explanation earlier this month. For years, the Chinese phone maker Huawei has provided codes so that the custom ROM development community could unlock the bootloaders of its device for years, making the firm a very popular choice with developers as it was only one of few companies that did so. The bootloader-unlock codes enabled users to do things like install custom recovery image software Team Win Recovery Project, use custom ROMs, or get root access to the device. Naturally, Huawei spun the decision as a good thing for customers that would immeasurably improve the "user experience", largely by protecting them from themselves. "In order to deliver the best user experience and prevent users from experiencing possible issues that could arise from ROM flashing, including system failure, stuttering, worsened battery performance, and the risk of data being compromised, Huawei will cease providing bootloader unlock codes for devices launched after May 25, 2018," the firm burbled. It continued: "For devices launched prior to the aforementioned date, the termination of the bootloader code application service will come into effect 60 days after today's announcement. "Moving forward, Huawei remains committed to providing quality services and experiences to its customers. Thank you for your continued support." The move is quite a big blow to the developer and modding community. Many considered Huawei to be one of the few developer-friendly OEMs. However, by ending the support and not giving unlock codes, Huawei's devices will now be much less desirable to developers. Source
  13. Apple's App Store on iOS has generally been pretty successful, and last year's holiday season bore testimony to that. But while the company may have been celebrating those numbers, some developers feel like the App Store isn't the best environment for them. At least, that's the case made by a new group called The Developers Union. Despite the name, this is an unofficial union meant to "bring developers and supporters together for better App Stores for all". At the time of writing, the group has just over 400 supporters including developers and non-developers, but Wired reports that the union hopes to reach 20,000 in early June, in time for Apple's WWDC. In an open letter to Apple, the group starts by asking the company to allow every app on the platform to free trials before July 2019. The developers have called on the company to commit to this change in time for the tenth anniversary of the App Store, which happens in July of the current year. The group explains why free trials are so important: Once that goal is achieved, the group will focus on what it considers a "more reasonable revenue cut" for developers. Apple currently takes 30% of the money spent by users on apps and in-app purchases, which is more than what Microsoft takes even before the new revenue share announced at this year's Build. It's hard to predict if the company will cave to the requests of the group, even if it reaches its target number of members. If that does happen, the unofficial union says it will continue to strive for more "community-driven, developer-friendly changes" going forward. Source details < Clic here >
  14. Today, Mozilla is announcing a plan that grows collaboration with Microsoft, Google, and other industry leaders on MDN Web Docs. The goal is to consolidate information about web development for multiple browsers – not just Firefox. To support this collaboration, we’re forming a Product Advisory Board that will formalize existing relationships and guide our progress in the years to come. Why are we doing this? To make web development just a little easier. “One common thread we hear from web developers is that documentation on how to build for the cross-browser web is too fragmented,” said Daniel Appelquist, Director of Developer Advocacy at Samsung Internet and Co-Chair of W3C’s Technical Architecture Group. “I’m excited to be part of the efforts being made with MDN Web Docs to address this issue and to bring better and more comprehensive documentation to developers worldwide.” More than six million web developers and designers currently visit MDN Web Docs each month – and readership is growing at a spectacular rate of 40 percent, year over year. Popular content includes articles and tutorials on JavaScript, CSS and HTML, as well as detailed, comprehensive documentation of new technologies like Web APIs. Community contributions are at the core of MDN’s success. Thousands of volunteers have helped build and refine MDN over the past 12 years. In this year alone, 8,021 users made 76,203 edits, greatly increasing the scope and quality of the content. Cross-browser documentation contributions include input from writers at Google and Microsoft; Microsoft writers have made more than 5,000 edits so far in 2017. This cross-browser collaboration adds valuable content on browser compatibility and new features of the web platform. Going forward, Microsoft writers will focus their Web API documentation efforts on MDN and will redirect relevant pages from Microsoft Developer Network to MDN. A Broader Focus Now, the new Product Advisory Board for MDN is creating a more formal way to absorb all that’s going on across browsers and standards groups. Initial board members include representatives from Microsoft, Google, Samsung, and the W3C, with additional members possible in the future. By strengthening our relationships with experts across the industry, the Product Advisory Board will ensure MDN documentation stays relevant, is browser-agnostic, and helps developers keep up with the most important aspects of the web platform. “The reach of the web across devices and platforms is what makes it unique, and Microsoft is committed to helping it continue to thrive,” said Jason Weber, Partner Director of Program Management, Microsoft Edge. “We’re thrilled to team up with Mozilla, Google, and Samsung to create a single, great web standards documentation set on MDN for web developers everywhere.” Mozilla’s vision for the MDN Product Advisory Board is to build collaboration that helps the MDN community, collectively, maintain MDN as the most comprehensive, complete, and trusted reference documenting the most important aspects of modern browsers and web standards. The board’s charter is to provide advice and feedback on MDN content strategy, strategic direction, and platform/site features. Mozilla remains committed to MDN as an open source reference for web developers, and Mozilla’s team of technical writers will continue to work on MDN and collaborate with volunteers and corporate contributors. “Google is committed to building a better web for both users and developers,” said Meggin Kearney, Lead Technical Writer, Web Developer Relations at Google. “We’re excited to work with Mozilla, Microsoft, and Samsung to help guide MDN towards becoming the best source of up-to-date, comprehensive documentation for developers on the web.” MDN directly supports Mozilla’s overarching mission. We strive to ensure the Internet is a global public resource that is open and accessible to all. We believe that our award-winning documentation helps web developers build better web experiences – which also adhere to established standards and work across platforms and devices. MDN Board Members Ali Spivak, Chair, Mozilla Daniel Appelquist, Samsung Internet Dominique Hazael-Massieux, W3C Meggin Kearney, Google Patrick Kettner, Microsoft Christopher Mills, Mozilla Erika Doyle Navara, Microsoft Robert Nyman, Google Kadir Topal, Mozilla Source Alternate Source - BleepingComputer
  15. Samsung is still the biggest smartphone seller in the world, and even though most of these sales are based on mid-tier smartphones, the company continues to dare the odds of R&D with its most recent experiments already on store shelves. Some of these experiments have gained a certain level of fame and others haven’t, but the company is clear that in order for most of these products to survive, it does need the support of the developer community. As such the company has just sent out invitations for its Samsung Developers Conference in November. The event will happen from November 11th to the 13th on San Francisco’s Moscone Center, and if you’re wondering what to expect for this event, we ask ourselves the same thing. In previous years we’ve seen Samsung announce its Mobile SDK, the KNOX Enterprise SDK, among other things, but none of these have gained enough popularity or traction for this event to be noticeable. We are expecting to see enhancements on Samsung’s S Health platform, and we also expect to see a bigger push towards Tizen devices now that we have all of Samsung’s Gear lineup running its proprietary operating system. It’s hard to predict if we will also see some extra push on devices like the Samsung Z for markets like the United States, but stay tuned as rumors should get more interesting in the next coming weeks. Source
  16. Looking for an Android device to test your app on but don't have access to the latest hardware? If you live in US or Canada, LG has got you covered. B) Android developers in the above mentioned areas can now sign up for LG's developer program to request an LG G2 or even the older Optimus G Pro and Optimus G for up to 30 days to test their applications on. Interested, Sign up for the LG Device Loaner Program source: gsmarena
  17. Samsung started its first developer conference this week in San Francisco and while talk of Android filled the air, Samsung also made sure that Tizen had a presence too. Most of the talk about Tizen took place between scheduled talks, amongst developers. The main focus of the conference was to push developers to make Android apps unique to Samsung models. One analyst sees this all being done in preparation for the day that Tizen is made available, to show developers that Samsung can take care of them even when they start writing for the OS developed by Samsung and Intel. This way, the transition to Tizen from Android will be a smooth one. Samsung is developing Tizen as an OS it can focus on if Google starts punishing Samsung for dominating the Android platform. Word is that problems with its app store has caused a delay in the launch of a Tizen powered handset. The latest buzz is that we will see a Tizen powered phone launch at CES 2014 in January. Meanwhile, both Sammy and Intel have been talking to code jockeys, trying to get them to commit to Tizen. Because Tizen apps are written in HTML5, a world class browser is being built for the platform. The lone Tizen talk on the schedule was sparsely attended even though positive features for Tizen were discussed. Alexis Menard and Kenneth Christiansen, two software engineers at Intel, said that the platform is responsive in that it can cover various screen sizes, and also has an API for features like the battery. Ebay says that it is considering building a Tizen powered app because it see the platform eventually being used in smartphones purchased in emerging markets. source: phonearena
  • Create New...