Items tagged with: bugs
DARPA says absolutely the right way to develop technology - "for dangerous missions, such as hazardous monitoring and emergency relief operations"
Can't you just see one of these #bugs #traveling in-between downed I-Beams, rubble, looking for survivors during a major disaster? DARPA scientists most certainly feel one of the mosquito-sized drones will certainly be able to do the job - considering the autonomous AI that will be controlling the micro-engines driving it.
Have they solved the battery power issue? Typical drones run for mere moments for that sized payload, a micro-hand-held drone a couple inches across runs for about 3 minutes before crashing.
What breakthrough in advanced power is in the Mosquito allowing to have a long duration mission?
Does it leach power from the environment in some way?
Think that DARPA is out there to just develop benign drones to just listen to the "enemy", or assist in a disaster to find people buried in rubble? Maybe thinking again would be a wise idea..
Draper Industries has already attached a #cyborg control system to a #dragonfly (an organic living creature) to put it under control of the "drone operator"..
ref - https://spectrum.ieee.org/automaton/...e-takes-flight
Why the dragon fly? It can carry a bigger payload and it's battery pack is used for the control electronics, not the flight muscles (the dragon fly uses carbohydrate food to power itself) - so the range is greater..
You find a bug in macOS or iOS. Something in the software isn’t working the way it should work. You decide to let Apple know, and head over to login with your Apple ID. You fill out the required fo…
Article word count: 1631
HN Discussion: https://news.ycombinator.com/item?id=19349638
Posted by fireflies_ (karma: 71)
Post stats: Points: 113 - Comments: 35 - 2019-03-10T01:23:17Z
#HackerNews #apple #bugs #for #logging #sad #state #the
You find a bug in macOS or iOS. Something in the software isn’t working the way it should work. You decide to let Apple know, and head over to http://bugreport.apple.com and login with your Apple ID. You fill out the required form, list the reproduction steps, hit the special key chord to generate a fat sysdiagnose, attach some screen shots, and hope they fix it.
What happens to your bug?
All bugs are tracked with an internal application called Radar; internal Apple employees simply log bugs directly into this application. External people use the website “Bug Reporter”, which only shows specific developer interactions with the bug, and hide all other details of the bug. Those details are engineer comments, progress on the bug, when they “expect” to fix it or which build it is fixed in, and priority. Priority is important for bugs; they are considered “unscreened” if they don’t have a priority set. Bugs with a high priority (1) are highly likely to get fixed, whereas bugs with a lower priority (3 or 4) are not likely to ever get fixed.
Each bug is placed into a particular top level component, which can have sub components. Savvy internal developers will log bugs directly into the component that the bug corresponds to, such as “AppKit / NSTableView”. This will get it directly to the right person who needs to look at it. Top level components have a large dropping areas that generic bugs can fall into, such as “iTunes / All”. These components get saturated with bug reports.
Once your bug hits Radar someone will look at it. Developer Support will often take a first look at bugs that are related to SDK/programming issues. They will then pass it on to a more specific top level component, or directly to a more specific component (ie: NSWindow).
This is where things get screwy depending on the component your bug lands in, since bug management is group dependent. Many groups will have only one or two QA people to do the initial screening of those large drop areas for bugs. QA engineers are sometimes instructed to screen bugs with a priority and “fix period” before passing them off to the engineer responsible for the code. This is terrible because many engineers will not look at bugs with a low priority. It is much better for the engineer who “owns the code” to look at a bug and determine the priority. The QA engineers will frequently get a huge back log of bugs to screen, and it can take weeks, or even months, for some bugs to get screened. Sometimes this leads to a mass screening of bugs, marking them all with a low priority. Bug originators have to notice this, and complain about it for the priority to get increased. Worse yet, some groups mass close bugs older than a year or so, and ask the originator to re-open the bug if the issue still exists. A lot of people don’t pay attention to bugs that need verification, and they simply become lost.
From an internal developer’s perspective, it was quite frustrating to take the time to log a detailed bug, only to see it sit “unscreened” for weeks and weeks. It is demoralizing to see this happen to your bugs. But worse yet, sometimes your bug would get forward-duped. Someone else at a later time logs the same bug, and your older bug report gets duplicated to it. More often than not, this is simply because of the delayed screening of bugs.
From an external developer’s perspective, it is even worse. There is very little feedback on bugs when they are in progress. You don’t know what priority the bug has, or if it has even been looked at and screened. This is Apple internationally being opaque. More transparency could easily leak features or products, so this is expected.
Hopefully a bug ends up with an individual engineer who works on the code. A lot of these bugs will still be unscreened, and Apple engineers seem to loathe the process of screening bugs. So they let them sit around for a while, sometimes for weeks or months. People would rather focus on coding something new up, or working on already screened bugs that they have to fix, as opposed to taking the time to read a bug report and figure out what needs to be done with it. They don’t have to read it and fix it right then, but just do a screening: determine priority, when to fix it (this is sometimes nebulous), and possibly ask the originator for more information (or mark it as a duplicate.)
Engineers also dislike screening bugs because sometimes they have to add them to their queue for the current release. This increases their required workload for that release, which is something people don’t like doing. So, instead, many bugs stay unscreened.
Unscreened bugs indicate potential software problems that need to be fixed. Obviously this is bad, and management doesn’t like to have high unscreened bug counts. Managers will frequently instruct engineers to screen bugs, or ask QA engineers to do it (which is bad).
Sometimes QA screen bugs with a low priority and holds onto them. They never get moved to the appropriate code engineers, and effectively become lost in the system. Sadly, I had seen this happen way too often.
Bugs screened with a low priority and a nebulous-future fix date are also lost. They rarely will be revisited and fixed. Sometimes this is okay. Some bugs are just too obscure or rare to spend time fixing.
Some bug owners don’t want to take the time to go back and forth with the originator to find out some piece of information they may need. They sit on bugs for a long time, and eventually try to reproduce a bug on a later version of the un-released OS. They can’t reproduce it, so they just assume it is fixed, and send it back to the originator. This is particularly bad for external developers, and I’ll describe why below.
When a bug is sent back as fixed, the internal developer who originated the bug is supposed to verify the problem is resolved. They can send it back if the problem isn’t resolved. However, internal developers don’t really have an incentive to verify bugs. Management doesn’t keep track of bugs that need verification or really require developers to verify them. Most engineers do verify bugs; they like to make sure problems are resolved. But external developers are left in a more sad state. The bug becomes closed for them, and is dead.
External developers do get notified when bugs are fixed, but only after the fix is available in a public release of the OS. This means it could take about a year for some bugs to get back to the external developer, since bugs start to get fixed before an OS is released to the public. Generally, the bug will ask the external developer to verify the bug by installing the latest OS. For some people, including me, this just isn’t possible; they need to run and support an older OS, and don’t have the ability to install a newer OS on a particular machine. Or, they just won’t want to install the latest OS because it doesn’t have anything they want or need (that’s me, I run 10.13). Even if they do install the OS, they may find the bug isn’t fixed. At this point, it is simply too late; engineering has likely closed the bug, and it is lost in the ether.
What can Apple do?
It is simple: Internal engineers need to take more responsibility in promptly screening bugs. Management needs to allow engineers to have more time to do this, which is at the expense of working on features or fixing already screened bugs. Engineers should always be expected to have a very low unscreened bug count.
Internal engineers need to promptly verify bugs when they are sent back to them. They need to install beta versions of the OS and do some testing. If it isn’t fixed, send it back.
If a bug report refers to some problem, then the developer should look at the code that interacts with the area described and try to think about what would cause such a problem to happen. For instance, if a button is incorrectly disabled in iTunes, then the developer should try to figure out why that could happen instead of just asking for “how to reproduce this?”
When I worked at Apple I practiced what I am now preaching. I would screen all my bugs within a day or so. I would verify bugs within a week or so. I would poke around at code and attempt to make theoretical fixes for bugs I couldn’t reproduce. I felt like it was part of my job, and I just did these things as a daily task.
What can you do?
Obviously, you have to log bug reports. It’s okay to log bugs that are missing information; developers can ask for specifics of what they need. In general, for AppKit related bugs, I would find that a “sysdiagnose” rarely would provide any useful information. I would hate it when people (usually QA, and not the engineers who worked on the code) would ask me for a sysdiagnose, when I know it wouldn’t help them figure anything out.
Log duplicates. If you know someone else logged a bug, but you are encountering the same issue, then log the same bug. It will get marked as a duplicate, but this will help increase the priority of a bug. It is sad, but Apple does look at this, and bugs with “high dupe counts” are looked at.
HackerNewsBot debug: Calculated post rank: 87 - Loop: 119 - Rank min: 80 - Author rank: 142
[EN] On the Shadow battle stage in Kingdom Rush: Frontiers with a hero Kahz one of the lizards with whips (possibly after being rushed by the hero) went not down (towards my base) but up – towards the boss with his crystal. I lost 5 HP anyway. Is that even legal? XD
#lang ru #игры #баги #kingdom rush #lang en #games #bugs
Percentage of memory safety issues has been hovering at 70 percent for the past 12 years.
Article word count: 340
HN Discussion: https://news.ycombinator.com/item?id=19138602
Posted by clouddrover (karma: 3782)
Post stats: Points: 109 - Comments: 95 - 2019-02-11T21:39:31Z
#HackerNews #all #are #bugs #issues #memory #microsoft #percent #safety #security
Microsoft memory safety trends Image: Matt Miller
Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues; a Microsoft engineer revealed last week at a security conference.
Memory safety is a term used by software and security engineers to describe applications that access the operating systemʼs memory in a way that doesnʼt cause errors.
Memory safety bugs happen when software, accidentally or intentionally, accesses system memory in a way that exceeds its allocated size and memory addresses.
Users who often read vulnerability reports come across terms over and over again. Terms like buffer overflow, race condition, page fault, null pointer, stack exhaustion, heap exhaustion/corruption, use after free, or double free --all describe memory safety vulnerabilities.
Speaking at the BlueHat security conference in Israel last week, Microsoft security engineer Matt Miller said that over the last 12 years, around 70 percent of all Microsoft patches were fixes for memory safety bugs.
The reason for this high percentage is because Windows has been written mostly in C and C++, two "memory-unsafe" programming languages that allow developers fine-grained control of the memory addresses where their code can be executed. One slip-up in the developersʼ memory management code can lead to a slew of memory safety errors that attackers can exploit with dangerous and intrusive consequences --such as remote code execution or elevation of privilege flaws.
Memory safety errors are todayʼs biggest attack surface for hackers, and attackers appear to be capitalizing on their availability. According to Millerʼs presentation, use after free and heap corruption vulnerabilities continue to be the preferred bugs when attackers are developing exploits.
Microsoft memory safety bug exploited trends Image: Matt Miller Microsoft memory safety bug root causes Image: Matt Miller
Furthermore, as Microsoft has patched most of the basic memory safety bugs, attackers and bug hunters have also stepped up their game, moving from basic memory errors that spew code into adjacent memory to more complex exploits that run code at desired memory addresses, ideal for targeting others apps and processes running on the system.
Microsoft memory safety adjacency Image: Matt Miller
Microsoft Surface Go: First impressions SEE FULL GALLERY
[IMG]Related security coverage:
HackerNewsBot debug: Calculated post rank: 104 - Loop: 144 - Rank min: 100 - Author rank: 55
196 votes and 101 comments so far on Reddit
Article word count: 327
HN Discussion: https://news.ycombinator.com/item?id=19131272
Posted by mbrodersen (karma: 143)
Post stats: Points: 121 - Comments: 92 - 2019-02-11T00:55:54Z
#HackerNews #airbnb #been #bugs #could #have #prevented #types #using
I obviously donʼt agree with calling him an idiot, but tbh, itʼs a very low quality article, his graph of conclusions are arbitrary and absurd, and the statistical malpractice on display is almost physically painful. His claim that "thereʼs little evidence that type safety reduces bugs" links to a Medium article.... Written by him... Referencing a studies of bug density that simply look at Github repos, their languages, and the number of issues labeled "bug". If you canʼt see a million sources of skew polluting this data, I donʼt know what to tell you.... An easy one off the top of my head (that comports with my experiences at FAANG and beyond) is that the choice of language for a project isnʼt independent of how complex the project is, or how much attention it gets, and both of these have obvious correlations with the metrics for bug density in the study that have nothing to do with the languageʼs contribution to bug density.
Im far from a static-typing fanatic: my last job involved building a tech org from scratch, and I picked python for our backend and would do it again (despite personally hating every minute of it) for a variety of reasons: the low quality of the engineers in our pipeline, the ease with which we could go into tech debt for quick feature changes, etc etc. Elliot touches on these points, but he doesnʼt even attempt to mount a serious defense of the skew between the large positive scores he places on them and the low weight he places on static typing benefits. Again, I wouldnʼt go as far as "idiot" but it makes me pretty skeptical of his engineering ability and that of those heʼs worked with. (FWIW, if my last company had been built with a couple of friends at roughly my engineering ability, I absolutely wouldʼve gone with a statically-typed language, from personal experience with the level of productivity and stability it engenders).
HackerNewsBot debug: Calculated post rank: 111 - Loop: 75 - Rank min: 100 - Author rank: 8