Blender 2.79: OpenCL on par with CUDA - <AUTHOR> https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/OpenCL <comment><USER3> There was an article on here a couple of months back that was an intro to blender from a geek / vim perspective. I felt a bit inspired and downloaded it to have a play. It's an absolutely brilliant application - I highly recommend giving it a try.

Edit here's the post [https://news.ycombinator.com/item?id=13379597](https://news.ycombinator.com/item?id=13379597)

<comment><USER4> Having learned blender first is likely why Vim was so appealing to me.

Blender's UI is so much better this way. The idea that the functionality of any professional software tool should be immediately visible is just silly. Photoshop, GIMP, Autocad, 3DS Max, Maya, etc. all follow that philosophy, and just end up with way too many buttons and menus for anyone to want to sift through. Blender shows functionality only where it is needed in the most beautiful modular system I have ever used.

<comment><USER3> Agreed. It felt really streamlined and the mental model felt instantly comfortable. If you want to rotate something you can select - rotate - <USER2> axis - choose degree, all in a very programmatic way.

One thing I ran into was it seemed there are some shortcuts that are essential and basically wired to the number pad so I had to buy an external keyboard (and non trackpad mouse).

I haven't had time to get back to it again but I'm looking forward to sitting down and having another good play.

Edit I'm not super familiar with autocad but I make software for construction companies so I've seen it used a bit. You can do everything in a vim like command manner. I think it had a lisp prompt.

<comment><USER5> If you toggle `File -> User Preferences -> Input -> Emulate Numpad` you can have the usual number keys work like the numpad. I actually prefer it that way to so I can change the camera without having to move my hand all the way to the right of the keyboard.

</comment></comment></comment></comment><comment><USER6> Quoted from the article:

"OpenCL works fine on NVIDIA cards, but performance is reasonably slower (up to 2x slowdown) compared to CUDA, so it doesn't really worth using OpenCL on NVIDIA cards at this moment."

I wonder if that's intentional on NVIDIA's part.

Does it mention which version of OpenCL they're using? I'm looking forward to hearing news about v2.x and SPIR-V.

<comment><USER7> I don't think it has anything to do with the driver itself. At least in my experience, the custom code you write performs more or less the same across both CUDA and OpenCL. The issues arise when you are using the toolkit libraries (like BLAS and FFT). cuBLAS and cuFFT are much much tuned for NVIDIA hardware than any OpenCL versions available at the moment.

<comment><USER8> Are there any pain points for cuBLAS and cuFFT?

<comment><USER7> Not really, but they are only supported in CUDA. For OpenCL you will have to use clBLAs and clFFT (written and maintained by AMD). This means they are not exactly tuned for other architectures.

<comment><USER9> I prefer to use OpenCL, but I think the second key factor why Nvidia dominates (the first is they integrated tooling) is that cuBLAS, cuFFT, cuDNN et.al work out of the box when you install CUDA Toolkit. clBLAS and clFFT? Good luck using them even on AMD hardware, yet alone on someone else's. And, of course, there is no cuDNN equivalent (that is beyond experimental)...

</comment></comment></comment></comment></comment><comment><USER10> Blender's progress has been astounding. I remember a while back they anounced the OpenCL implementation was being put on hold for a undetermined amount of time due to limitations with AMD cards. This really is an exciting announcement. It's great to see it on HN too.

<comment><USER11> Blender is probably one of the most successful OSS projects since Linux. In the span of five years, you wouldn't be caught dead using it over Maya. Now, its visa versa.

<comment><USER12> It is espacially amazing given:

\- the problem blender is solving is super hard

\- the competition was way ahead

\- FOSS don't have great track record for this kind of challenge (gimp has never replaced photoshop nor LibreOffice MSO)

\- they don't have that much resources

\- professionals are very demanding

\- the graphic space is not really foss friendly

\- the amount of work they poured into this is incredible

They are heroes really.

<comment><USER13> One of the reasons for their success are the Open Movie and Open Game projects[0]. It forces them to actually accommodate the needs of working artists and designers in their tool. It also showcases the power of Blender and gets the attention of potential users. The production values are actually pretty good for the projects which get's peoples attention.

[0]: [https://www.blender.org/features/projects/](https://www.blender.org/features/projects/)

<comment><USER14> I think the main reason is good software design.

It's so modular that it's very easy to extend.

A new fluid sim algorithm? A few months later Blender is shipping it.

That's also the reason it's fast. It starts in one or two seconds.

<comment><USER15> I can't talk about the specifics of the software design.

But if you take into account how the Blender project is handled with consideration of how to sustain itself via the Blender Foundation, and all the related projects, you can observe how an outlier it is compared to all similar ambitious projects that are not doing so well.

This is a bad and a good sign: it makes evident how little FOSS projects take in account it's sustainability over time, on the other hand it presents an opportunity for huge improvements in this area.

</comment></comment></comment></comment></comment></comment><comment><USER16> The performance of OpenCL has generally been fine for me, particularly on AMD GPUs, but I have to say I think CUDA is a lot simpler to work with.

OpenCL is one of those things that I never felt fully comfortable working with, but I felt productive in CUDA after a week or two. Granted, I learned them in that order, so it's possible that CUDA got an unfair head-start, but I stand by my initial thesis.

<comment> shawn-butler You might want to take a look at SYCL for higher-level abstractions if that was your preference.

There is an open-source implementation to dig into: [https://github.com/Xilinx/triSYCL](https://github.com/Xilinx/triSYCL)

<comment><USER16> Actually, nowadays since I mostly do esoteric functional stuff, I mostly use the wonderful `accelerate` package for Haskell: [https://www.stackage.org/package/accelerate](https://www.stackage.org/package/accelerate)

It abstracts away most of the difficult stuff.

<comment><USER17> Out of curiosity, what are you doing with Accelerate? I've been looking for examples of people using it in anger.

<comment><USER16> I can't get into the weeds of it because of some NDA chicanery, but there are a couple vector transformations that I have to do on a not-quite-big-data-but- also-too-big-for-regular-CPU set of data. The initial version of the project was doing some basic stuff in Python, but that proved to be slow so I rewrote most of it in Haskell and Accelerate.

</comment></comment></comment></comment></comment><comment><USER18> I don't quite get this page; isn't it more accurate to say 'amd on par with nvidia'? It seems for amd they use opencl, for nvidia cuda; but you can run opencl on nvidia too (1.2 only, apart from experimental, partial 2.0 support in the very latest drivers, but still).

I mean, there are numerical libraries that run 2x as fast on nvidia compared to their most optimized opencl implementations, because they use 'gpu assembly' specific for nvidia cards; how does that fit the 'opencl on par with cuda' claim? It depends on what effort is spent on optimizing for a certain platform, not what api is used...

I'm working in opencl myself but it's frustrating that I'll never get as much performance as I would when using opencl, even when I'm using gtx gpus myself.

<comment><USER19> > as I would when using opencl

Didn't you mean CUDA?

<comment><USER18> Yes I did, mixed that up, thanks.

</comment></comment></comment><comment><USER20> Cuda -> OpenCL transpiler:

[https://github.com/cuda-on-cl/cuda-on-cl](https://github.com/cuda-on-cl/cuda- on-cl)

</comment><comment><USER21> Blender is a really fun program to use, Tons of tutorials and information on youtube etc... I think more education could use 3d programs like this to help with algorithm visualization.

I made this video about worker in tech with blender.

[https://vimeo.com/98728314](https://vimeo.com/98728314)

The worker is slaving away at his terminal, he is writing code that creates the 'feed' of apps/entertainment/media/etc.. for the insatiable appetite of society (Represented by the somewhat-similar-to-a-hungry-hippo character in the depths). Who are these other two glowing beings? What do they represent? My friends have tried to guess some explanations, but I'll let each audience member decide for themselves.

</comment><comment><USER22> Would it be a completely stupid idea to write a CUDA-based OpenCL back-end? i.e., an OpenCL-to-CUDA translator, so you can program your kernels in one single language but still get the benefit of the NVidia CUDA compiler?

Or are their machine models so different that that is an unreasonable thing to even try..

<comment><USER23> It's likely better to just write/use libs which abstract the CUDA/OpenCL level away for generic GPU type tasks. Unless you have really strict performance requirements or are writing a very specific piece of GPU code, in which case I cant image OpenCL-to-CUDA translator would handle that case well either.

They both have very similar ideas for the core of the APIs then CUDA adds a bunch of stuff on top of it for ease of use and performance which is tightly coupled with the hardware in some cases. It would be a lowest common denominator situation with a lot of those features in CUDA.

</comment></comment><comment><USER24> What part of that page says it has to do with version 2.79 of Blender though?

I think the actual page that talks about Cycles rendering performance improvements in version 2.79 is this wiki page: [https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.7...](https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.79/Cycles)

But that page doesn't seem to mention any comparison between OpenCL and CUDA.

I think something is still missing to make a concrete link between "OpenCL on par with CUDA" and version 2.79 specifically.

</comment><comment><USER25> It looks significantly faster in those benchmarks! Koro takes almost half as long!

<comment><USER26> That's nvidia on opencl not cuda.

<comment><USER27> That's not clear, the chart just says "comparison of cards", the article does not mention how it was made

<comment><USER26> The entire page is talking about opencl, unless it's deliberately misleading it's pretty clear it's opencl.

</comment></comment></comment></comment><comment><USER28> Anyone knows how to get OpenCL working on Linux using the open source AMDGPU driver (not the AMDGPU-PRO driver which is their proprietary driver)?

<comment><USER29> As the other poster said, you need Clover, and then you can use clinfo [1] to check you have everything installed and working.

I can't say for sure what's the latest state of Blender; somebody on Freenode #radeon mentioned a few months ago that Blender is failing to compile its OpenCL kernel, while before that somebody mentioned it as working, but quite a bit slower than with the proprietary driver. I suggest to try it yourself and report any bugs you encounter as blocking [2].

[1] [https://github.com/Oblomov/clinfo](https://github.com/Oblomov/clinfo)

[2] [https://bugs.freedesktop.org/show_bug.cgi?id=99553](https://bugs.freedesktop.org/show_bug.cgi?id=99553)

</comment></comment><comment><USER30> Either way, this has no effect.

The 3D artists using GPU production rendering require at least 4 of the top of the line cards for their workstation. My workstation crams x5 980Tis in the case (2 off the board with PCIe risers).

Joining the community using this approach not only requires the hardware and ability to build it but also new rendering software and a lot of time to learn a new approach/mindset/workflow. The best software available is crucial. It is worth every penny to invest in the best rendering software when entering this environment. Right now, there are 3 that matter and none of the GPU-specific remdering softwares support OpenCL. There is a unique exception with V-Ray, the last gen maverick of rendering engines. V-Ray's future in GPU rendering could be bright if the new companies don't entirely outpace them in GPu development. Either way, every part of the people actually using this solution in the real world is investing all of their time, money, energy into Nvidia right now.

The devs at Redshift, my chosen renderer, insist OpenCL is not even close to having what they need.

Pseudo-realtime feedback could actually advance the craft to a new era and Nvidia is carrying the entire ecosystem.

<comment><USER31> Just out of curiosity (it's not my field), what are those 3 renderers that matter right now?

Somehow I read your comment as V-Ray is not among them as being last-gen. I remember that years ago there was a lot of buzz regarding Arnold (and it was justified to some extent AFAIR, at least judging by opinions of pleased 3D crowd), but maybe it's last-gen too now? Many years ago there was Brazil, but quick googling shows it's only for Rhino now? I haven't heard about Redshift till now, though.

<comment><USER30> The 3 GPU renderers that matter are: V-Ray RT, Octane, Redshift

CPU renderers are a different story but Arnold is right up there with V-Ray. CPU renderers are tried and true, reliable and robust.

V-Ray is the only company making both CPU and GPU renderers. The GPU version can render most of the same shaders but the backward compatibility requirements slow it's progress. It's OpenCL support is always behind CUDA as well.</comment></comment></comment>


Advanced Codemunging: How SICP, Emacs, and Lisp Change Your Day Job Performance - <AUTHOR> http://lispy.wordpress.com/2008/05/13/advanced-codemunging-a-report-from-the-trenches/ <comment><USER2> His essay here touches lightly on a pattern I've noticed among people who work in large corporations: they fall into the habit of asking for permission and guidance too often.

It doesn't make any sense to complain about inept suggestions or withheld permission when the problem could have been solved or a critical decision could have been made without blessing from above. Invariably though, if you ask for permission, now you really do need it.

Many of the greatest projects that have ever come out of large corporations happened because the innovators didn't ask or wait for permission (e.g. Unix).

<comment><USER3> "It doesn't make any sense to complain about inept suggestions or withheld permission when the problem could have been solved or a critical decision could have been made without blessing from above."

The trouble is, if you try to solve a problem you weren't asked (told) to, or use new and 'unapproved' methods, and anything goes even slightly wrong, you'll be in serious trouble.

If you do what you're told and use the 'approved' methods, your job will be safe in the short term - no matter how unsatisfactory the end result.

"Many of the greatest projects that have ever come out of large corporations happened because the innovators didn't ask or wait for permission (e.g. Unix)."

Longer term, yes, I think you're right.

<comment><USER4> I think it's worse to be stuck with responsibility for a codebase that you have no real authority over.

You can't live in fear of that kind of stuff. Who's the fricking expert on software development? Not the managers. If you focus on meeting everyone's needs lower down on the food chain-- and invest in tools in techniques that multiply your ability to maintain and extend the code-- then your development will be so tight and your response to issues will be so comprehensive that the "play it safe" types will have nothing they can say to you. (Except maybe that they'd rather have more buttons or something.) If you're a responisible developer, you'll be addressing the "slightly wrong" stuff well before the middle managers even hear about it. You'll have a relationship with the real value-adders such that they talk to you instead of your bosses. You, after all, are the one that gets stuff done quietly and thoroughly.

Sheesh. They're "play it safe" types. Think about it. Once the code is up and running, _they're_ not going to be to be suggesting any changes. Suddenly you're the status quo and they'll defend your work by saying "if it ain't broke don't fix it" just like they said about the previous solution.</comment></comment></comment>


Bayes.js: A Small Library for Doing MCMC in the Browser - <AUTHOR> http://sumsar.net/blog/2015/12/bayes-js-a-small-library-for-doing-mcmc-in-the-browser/ <comment><USER2> Cool library! I think there are a lot of researchers who are interested in using bayesian models, but need to see them in action in a very gentle way first. Implementing a demo in the browser for a bayesian approach you're trying to sell people on seems like a nice, low energy way to give them a simple, working example.</comment>


Lenovo ThinkPad X1 Carbon Review - <AUTHOR> http://www.thinkscopes.com/blog/2015/01/06/lenovo-thinkpad-x1-carbon-gen-3-review-2 <comment><USER2> I really wanted to consider the X1 Carbon this last spring but two things stopped me. The function row and the 8GB RAM.

I ended up with a w540 - it has 2880x1620px 15.4" screen and the battery life has been great under Ubuntu (5-6hrs) if a bit less than it gets under Windows (6-7hrs). But I got 16GB of RAM and it can go up to 32GB.

<comment><USER3> My MBP Retina is similarly powerful, 16G, and gets 10 hours of browsing or document editing.

<comment><USER4> Also heats up like crazy and battery life goes to about 1.5-2hrs if all cores are used. I don't get the powerful part if you aren't using the power.

<comment><USER5> I haven't had this experience at least. I get about 7 hours if I'm doing light web browsing, and about 3.5 if I'm working (Xcode + Parallels running Win7 which is running CodeComposer). First gen MBPr.

</comment></comment></comment></comment><comment><USER6> Pretty decent review. Glad to see Lenovo have back-peddled on the idiotic changes in their last generation (namely the keyboard/trackpad issues).

The ethernet thing seems lame however. Why must you buy a special card? They should have just left it off and instead given you another USB port in my view.

<comment><USER7> ...and I sincerely hope that 8GB is not the maximum memory.

<comment><USER8> Sorry friend, this is the case. There must only be one slot.

Interesting note re: RAM choices ... if you select the i5-5200U CPU on the Lenovo US website then you are allocated 4GB of RAM and have no option to select 8GB. The mid-range CPU (i5-5300U) allows you to select either 4GB or 8GB. Finally, if you select the i7-5600U then you are allocated 8GB and can't select 4GB.

<comment><USER3> There's no slots. Memory is soldered.

<comment><USER9> I wonder if it's technically useful or if it's a commercial move. I have an Ideapad Y470 (a model from 3 years ago), and I got the impression they tried to limit the RAM below what the hardware could run, maybe because they want to segment the market in a certain way.

The customization page on their website only allowed 8GB of memory and the user manual explicitly stated that the maximum RAM was 8GB. I bought 16GB after reading users reporting that it worked fine, and I can confirm: it works fine. I push it to the limit all the time.

Then again, it might just be that new RAM chips came out after the laptop did, and I might just be conspiracy-theorizing.

<comment><USER3> This is the logic board on the 2014 15" rMBP: [https://d3nevzfk7ii3be.cloudfront.net/igi/PmBmFGBkmnHDvEpo.h...](https://d3nevzfk7ii3be.cloudfront.net/igi/PmBmFGBkmnHDvEpo.huge). It's wedged between the fans and the batteries, and there's memory on both sides. If you make the board larger to put in SO-DIMM slots, you lose either battery or cooling capacity. The rMBP manages to fit a 15.4" screen and a 95Whr battery in 4.5 pounds. I've never seen an upgradable laptop that fits that much battery into that weight class.

</comment></comment></comment></comment></comment></comment><comment><USER10> Anyone have experience running Linux on this 2015 model? In the market for a new laptop and love that trackpoint.

<comment><USER11> I think it goes to show how slowly culture changes in hardware manufacturing that this isn't a checkbox feature that is in the press kit for new model releases.

From looking at the parts list, it seems like it ought to be reasonably easy to install and run linux ( even the WWAN card looks like it should work with the right drivers ) and yet it's not mentioned. It seems like they are missing out on a core market segment by not slapping a Linux Foundation badge on their website or box saying known to work with Kernel Version x.x and up. Or failing that I think both Canonical and Redhat would be glad to have their logo on there and all three orgs would only need a couple of days to validate on a pre-release model.

<comment><USER10> Looks like Canonical at least is doing that: [http://www.ubuntu.com/certification/hardware/201411-16196/](http://www.ubuntu.com/certification/hardware/201411-16196/)

"awarded the status of Certified Pre-Install for Ubuntu"

"Certification notes: Hibernate is not working on this system"

<comment><USER12> Be wary of Ubuntu's certification. I have a Lenovo X140e. It's certified to work with no issues[1], but I spent months fixing basic things like graphics acceleration and screen brightness. Though it has an 802.11n card, wifi transfers at G speeds. I still can't get Bluetooth to work. The X1's all-Intel hardware should fare better, but I'd still recommend waiting for a Linux- centric review before ordering.

1\. [http://www.ubuntu.com/certification/hardware/201309-14195/](http://www.ubuntu.com/certification/hardware/201309-14195/)

<comment><USER13> Did you get a preinstalled system? They make quite clear that standard images might not work with certain hardware which sounds exactly like what you are experiencing?

<comment><USER12> I tried, but I'm not sure Lenovo ever actually offered the X140e with Ubuntu preinstalled. The option isn't available on Lenovo's website. When customizing the order, OS choices are all Windows. I ended up buying over the phone, but couldn't get a Linux preinstall that way either. The person on the other end was just filling out a form similar to the one on the website.

Since I couldn't get Ubuntu preinstalled, I made sure to order the _exact_ hardware specified on Ubuntu's certification page: A4-5000 APU, BCM43142 Wifi/Bluetooth, etc. I also updated the BIOS to the latest version, which had fixes for Linux.

I realize I was rather unlucky. The X140e is not a popular piece of hardware. Next time, I'll be sure to pick something widely used.

<comment><USER14> As part of Ubuntu certification if an altered image is used then we supply that to the OEM. So Lenovo was given an image for the X140e - that's why the Cert page specifies a vendor image.

You have to request that image from the manufacturer. Probably through their support process. I don't know how it works for Lenovo.

The reason this happens is because hardware revisions and Linux kernel, and OS releases (e.g Ubuntu) are not in sync with each other. Eventually the changes for each hardware certification flows into the Ubuntu LTS release for that time. So, they probably went into 12.04.2 in this case. But, in some rare cases it's not possible for all changes to be taken - so generally it's best to get the preinstall image.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> Glad they smartened up, I ordered a top of the line one last year, opened the box... spent 15 minutes swearing as I packed it back up to send it back.

I have been a Mac guy since 2008, I wanted to get off the apple train and get a Lenovo as I loved Lenovo... only to find myself sitting here with another mac.

Replacing F1 keys with a touch bar? Really? Losing the Caps lock? No clue what they were thinking.

<comment><USER16> You actually use your caps lock key? I can't remember the last time I used mine and since I was never a Sun guy, I don't even bind it to Ctrl.

Not being snarky, just curious.

<comment><USER17> If you are used to binding caps lock to ctrl, the lack of that key is critical. I find it hard to do anything serious on machines without it now...

<comment><USER16> That's fair. I was assuming the parent commenter implied he or she used their caps lock key for its designed purpose, which in hindsight was perhaps an erroneous assumption.

</comment></comment></comment></comment><comment><USER18> Happy to see someone other than Apple adopting PCIe SSDs. Hearing that " _read speeds reached 1350+ MB /s_" is pretty freaking awesome! Crazy to see the difference between PCIe SSD and SATA SSD.

      Crystal Mark - Disk Mark

                        X1 Carbon Gen 3         X1 Carbon Gen 2
      Sequential Read   1362 MB/s (+161.11%)    521.6 MB/s
      Sequential Write  1227 MB/s (+394.16%)    248.3 MB/s
      512k Read         992.7 MB/s (+118.42%)   454.5 MB/s
      512k Write        1230 MB/s (+5224.67%)   23.1 MB/s
      4k Read           43.51 MB/s (+41.27%)    30.8 MB/s
      4k Write          96.15 MB/s (+2.83%)     93.5 MB/s

<comment><USER19> Apple has an (evil?) custom interface, so you can't just buy and plug-in an off-the-shelf PCIe SSD, like the new Samsung SM951.

</comment></comment><comment> andrey-g Old touchpad is back? Wonderful news. Damn i feel bad about upgrading to t440s now.

<comment><USER20> I'm searching around seeing if I can somehow replace the awful t440s touchpad. It's just so awful. I'm glad I rarely use it (emacs + tiling wm) but I'd love to use touchpoint more easily.

I would have killed if this was the Haswell x1, then I wouldn't have had to buy this t440s last year.

</comment></comment><comment><USER21> This machine with 16GB of RAM would probably be a good replacement for my current laptop. I only wish it didn't have the proprietary 'onelink' and 'ethernet' connectors, I know that those will go away and later this laptop will not be nearly as useful to me with just the single USB 3 port for stuff like RPI's, Bus Pirates, etc.

<comment><USER22> what you want is a t450s

<comment><USER21> Yes indeed, that is the machine for me.

<comment><USER23> T450s comes with 4GB RAM soldered: you can either have total of 8GB RAM dual- channel or 12 GB single-channel (don't do it).

</comment></comment></comment></comment><comment><USER24> X1 Carbon Gen 2 was Lenovo's Vista.

</comment><comment><USER25> Currently I have a 2013 Macbook Air, which I'm happy with everything about except for a) the keyboard, which I find too shallow and harsh for extended typing, and b) Office for Mac, which is a terrible substitute for the real thing. I'd be interested in getting this or the new Thinkpad Yoga, does anyone know how the keyboards compare? Obviously with the new models the keyboards may be improved compared to last gen but how good can a keyboard on an ultra- thin like the X1 be?

</comment><comment><USER26> How is the Broadwell CPU in it compared to Haswell chips in performance? It might say Core i7 but I thought Broadwell was basically a warmed over Atom processor. Performance from Broadwell on inexpensive tablets and laptops has not been great from what I read (battery life is of course quite good).

<comment><USER27> I think you are talking about Bay Trail, which powers the low end Chromebooks and is a replacement for the Haswell Celeron, not Broadwell in general. The new Bay Trail chips are indeed horribly slow compared to last gen Haswell Celerons (i.e. the one in Acer C720).

<comment><USER26> Ahh, that's probably it. Thanks!

</comment></comment></comment><comment><USER28> There is an even better review at Notebook Check:

[http://www.notebookcheck.net/Review-Update-Lenovo- ThinkPad-X...](http://www.notebookcheck.net/Review-Update-Lenovo- ThinkPad-X1-Carbon-Touch-20A7-002DGE-Ultrabook.113926.0.html)

<comment><USER18> FYI -- this is for the 2014 model, not the just released 2015 model.

</comment></comment><comment><USER29> I want a linux notebook. I have been waiting this for a while. but none of the review mentions linux comparability. The thing I mostly care about is the trackpad. Macbook's trackpad is just too great.

<comment><USER30> The Thinkpad X1 Carbon is, hands down, the best Linux laptop (IMO). But it was completely ruined in by the keyboard/mouse in Gen 2. Now that Gen 3 has fixed that, the X1C is king of the hill again.

        Macbook's trackpad

I'm a trackpoint guy, so avoid trackpads...

</comment></comment><comment><USER31> Can anyone here confirm if the X1 can run a Vagrant box without issue on Windows? I've had problems before on some ultrabooks that I cant get a proper VM running.

</comment><comment><USER32> Wish they had a removable battery.

<comment><AUTHOR> Check out the X250 - it has both a built-in and removable battery, which enables hotswapping.

<comment><USER33> But its screen is <13". Not really an apt comparison. I'd think the T450s would be a more suitable alternative.</comment></comment></comment>


Ask HN: Are UML diagrams still used today? - <AUTHOR> <comment><USER2> I think that entity-relation diagrams are underused, especially when analysing requirements with stake holders.

Unfortunately a lot of otherwise capable people that could benefit from some simple structuring of things and their relations have never thought about the world in that way and may take a little while to catch up.

In some cases I have found it to be easier to represent one-to-many relations as a bunch of stacked boxes on the "many" side. But that only works once...

Sequence diagrams and state-charts helps from time to time, but does not really help much when talking to non-professionals.

But I don't really like the very formal UML. Some bubbles, arrows and crow's feet will do fine in most cases. The precision promised by UML is really a lie, as most diagrams are simplifications and can probably not represent the actual complexity in anything that warrants the use of UML...

Anyway, I think it might actually be a good idea to do some simple entity- relationship analysis in schools at some point, if not to just get another tool for sorting out the mess.

The underlying reason that led to OO-languages still exists, namely that a lot of things can be described rather nicely with entity-relation maps. It's just unfortunate that the "relation" part was forgotten, and all energy was spent on wrestling various languages into bizarre "OO" hacks such as C++.

<comment><USER3> Entity relationship diagramming is such an incredibly simple at powerful tool - it's criminal it's not mandatory for a degree.

Doing modeling without it is like analysing logic with without boolean algebra or 1st order logic.

And thete is nothing to it - it just focuses your thinking and communication.

<comment><USER4> Where is it not mandatory for a CS degree?

<comment><USER5> I graduated a year ago and it was not mandatory at my University.

</comment></comment></comment></comment><comment><USER6> UML diagrams. I sometimes use sequence diagrams, but almost certainly with all the wrong symbols and so on. They're just parallel timelines showing communication between conceptual objects.

Otherwise, all I've ever seen anyone do is take their actual design diagrams and laboriously turn them into UML diagrams of some kind for a document. The recipient then took the UML diagrams from that and made their own new sketches from that, turning them into something they could easily read and understand and that generally looked very similar to the original diagram that was laboriously translated into UML.

My conclusion is that a UML diagram is better than nothing, but not as good as a well-written and well-explained design. I suspect UML diagrams are meant to be part of a well written, well-explained design, but for any given design there seems to be a better way to draw it than UML diagrams.

</comment><comment><USER7> In the sysadmin world yes but not nearly enough. UML along with similar ones like blockdiag and nwdiag interface nicely with my documentation systems in orgmode and asciidoc.

One of my side projects is an automated nwdiag mapping system with diff's to be able to help sysadmins coming in blind to orgs (happens way more than you'd think, usually a 5 yr old visio file somewhere).

Anyway, in the future I see uml style things as useful for similar automation projects, due to the simple text nature.

Also, I live in a terminal most of the time so personally prefer stuff like nwdiag over say visio or some of the alternatives.

I also used to make repair flowcharts with seqdiag for my t1 and 2s.

</comment><comment><USER8> I'm doing a degree part-time, online, and that's the only time I've ever used UML.

I work at a kind of graduated tech start up, so we're doing most things the modern way. I've never even heard anyone mention UML.

<comment><USER2> It's probably best to avoid Use Cases, (R)UP, and the associated process and document bloat, but a nice diagrams here and there can really simplify discussions.

Class diagrams are more or less useless, and it's mostly requested by non- professionals that can't read code. Use case diagram are more or less irrelevant too, with just an actor connected to one or two things.

I think that it's mostly administrative (in house) systems that models reality and complex processes that benefits from a modest dose of UML diagrams, not typical applications.

</comment></comment><comment><USER9> I've not seen anyone use any UML for years to be honest except for class diagrams or something similar to give a high level architecture overview or to explain how major components interact.

<comment><USER10> I still use traditional flowcharts, though only for personal consumption :^)

</comment></comment><comment><USER11> They are, but perhaps agile methods who diminish the importance of documenting have played against it. We will see what price we have to pay for this.

In my experience, people don't like to document, developers even more, and managers probably don't like to read documents, either. However, if people leave your company (something highly probable), how are you expected to train the new people?

If you are working in a startup, that's not major problem: the startup may just die and you can have fun programming in the meantime. However, if there is company that intends to last more than a few years, ways of documenting your system are needed.

IMHO, not using UML, or any other language, to think about our systems or even tell others how they work is a complete mistake. It is not only for telling others (colleagues and future workers) what the system does and why it does it that way, it is also to save effort and realize sooner that it will not work.

So, whatever the case, training in how to explain your system to others is required. Call it UML or whatever. And, since UML is there, it may be worth to use it. It is not just the invention of a couple of mad engineers. You are free to use UML as you like. And do not need to use a huge tool. Text UML is a nice and refreshing way of looking at UML which I strongly recommend. Have a look at [http://planttext.com](http://planttext.com), for instance.

</comment><comment><USER12> A few months ago I wrote this [https://news.ycombinator.com/item?id=12879493](https://news.ycombinator.com/item?id=12879493) and I think that's still valid.

Simplified UML class diagrams (i.e. boxes and arrows) are expedient for explaining specific aspects of a design. Complex class diagrams trying to give an all-encompassing picture of an application: Not so much.

Sequence and activity diagrams can be quite useful for clarifying application state, too.

</comment><comment><USER13> Yes (ex: with plantUML for a just quick DSL draws) and you can use Archimate too. ([http://www.archimatetool.com](http://www.archimatetool.com))

Are you using RUP? [https://en.wikipedia.org/wiki/Rational_Unified_Process](https://en.wikipedia.org/wiki/Rational_Unified_Process)

<comment><USER14> Thanks for linking to Archimate! I've been looking for similar software to build out attack trees when doing threat modeling.

I've been using these in the past [1] MonoDraw and this free [2] diagramming website. Came across [3] Draw today, although I have yet to try it.

[1] [https://monodraw.helftone.com/](https://monodraw.helftone.com/) [2] [https://www.websequencediagrams.com](https://www.websequencediagrams.com) [3] [https://www.draw.io/](https://www.draw.io/)

</comment></comment><comment><USER15> For software projects with new clients, I use cacoo.com and create simple domain and sequence diagrams to capture more complex workflows. I usually don't tell them it is UML and say these diagrams help better express workflows.

</comment><comment><USER16> I just call all my diagrams "boxes with arrows" nowadays ;)

<comment><USER17> Likewise, I create uml diagrams keeping them as standard as i can, but do not expect anyone else to know all the nuances of UML.

It amazes me the amount of time I see convoluted discussions when a simple diagram would make it so much simpler and explicit.

</comment></comment><comment><USER18> Where I work, we use it extensively for analysing problems and designing code. It's invaluable for communicating and collaborating on designs.

</comment><comment><USER19> Yes.

If they're used as an analysis/design tool and not as a documentation-after- the-code-is-written tool, with tools that generate code from the diagrams, they are really powerful.

I work in Embedded Software and mainly use: Use Case Diagrams, Statecharts, Sequence Diagrams, Component Diagrams, Class Diagrams. The 80/20 rule is true, and I think about 80% of the value comes from 20% of the entirety of UML.

</comment><comment><USER20> In the past 2 jobs even though it was just small startups with less than 5 devs, we used them in relatively critical or complex cases, but it wasn't anything formal (e.g. for every major component introduced do this).

I personally like them, maybe because I like thinking of the big picture no matter the task, plus we had extensive practice on uni.

</comment><comment><USER21> More than we tend to think. Less than I'd like.

But the key to benefiting from UML is to first decide what subset of the whole language you need and focus only on that. Very few companies will find a use for the 13 types of UML diagrams.

<comment><USER22> And have an actual methodology and process for its application.

</comment></comment><comment><USER23> Just for memo (for me or someone else):

For Python code, one can use pyreverse to generate UML representation.

</comment><comment><USER24> Of course! Great design starts with UML.</comment>


Let's make the web faster: PHP performance tips by Google - <AUTHOR> http://code.google.com/speed/articles/optimizing-php.html <comment><USER2> As someone who optimized a piece of PHP code recently, there are a number of things I ran into that were counterintuitive wrt performance.

\- array_key_exists is 5X slower than isset (though there are different semantics)

\- direct string concatenation is 2X faster than using "implode"

\- memoization can be a huge win since function calls are 5X slower than array accesses. (No inlining in PHP)

Of course, these optimizations don't matter except in your hotspots. (Why we still have to have this disclaimer on HN puzzles me, but people seem to keep trotting out the usual Knuth quote out of context as a way to write off micro- optimization techniques in general.)

Also important to keep in mind:

\- PHP has copy on write semantics for arrays. So if you set $foo = $bar (arrays), you don't incur any additional memory until you alter $foo. (Aside from the additional reference.) Once you change any entry of $foo, PHP makes a copy of the whole thing. (This can result in massive performance and memory bloat if you don't realize its happening.)

\- PHP arrays are not arrays, but are a hybrid linear array and hashtable. ("one data structure to rule them all.") So, even a simple "array" of integers incurs more than what you'd expect memory wise. In fact, IIRC, an array of integers incurs approximately 100 bytes of memory for each entry. Ouch. There are extensions in new versions of PHP that allow you to use 'real' arrays. If you're stuck using normal PHP arrays, good luck trying to design optimized data structures for the problem at hand.

See also: <http://phpbench.com/>

<comment><USER3> > There are extensions in new versions of PHP that allow you to use 'real' > arrays.

Where?

<comment><USER4> There is SplFixedArray <http://www.php.net/manual/en/class.splfixedarray.php>, not sure if this is the one he mentioned though.

</comment></comment></comment><comment><USER5> I wrote a PHP application (kind of a journey planner) a few months ago that at "beta" took about 1 minute to run each time due to all the processing it did. I spent a good few days speeding it up and making it use less memory and it now runs in under 10 seconds. Here's a few things I did that worked for me.

1\. Install APC and use it to cache objects as well as PHP files. Cache wherever possible. I used APC lots, as well as caching some heavy processing to disk. Cache results of expensive functions that are called many times in 1 script in a global or static variable.

2\. Unwrap lots of the lovely OO wrappers, such as the ORM (similar to ActiveRecord). This made the code messier but much faster. PHP takes a big hit every time it instantiates a new object.

3\. Take advantage of PHP's copy-on-write memory allocation; understand how PHP does garbage collection; use references where possible; understand what PHP is doing behind the scenes.

4\. Profile with xdebug and kcachegrind. Great for finding what's taking up the time and which functions are being called many times. Inline small functions that are called many times.

</comment><comment><USER6> Stopped reading after the first pointless micro-optimization. With some very rare exceptions, the cost of these kind of optimizations in terms of resulting in hard to maintain and change code are far greater than the cost of bluntly adding more hardware.

I mean seriously, if you're using PHP's OOP functionality but you find yourself having to squeeze out performance by dropping getters and setters on your classes, you should really first take a step back and take a good look at your entire approach.

<comment><USER7> I fully agree with that.

Those kinds of optimization may be sensible to tighten some critical inner loops of your code. But especially there you should avoid high-level features anyway.

Also, before trying to squeeze out performance that way, you might as well rewrite that part of your code in C, and let the C compiler perform _real_ optimizations.

However, chances are good that you don't even need that, as some intelligent combination of already existing fast PHP functions (implemented in C) usually does the trick.

</comment></comment><comment><USER8> Unfortunately, these tips were written by somebody who does not understand how PHP works. See detailed critique of the previous version here: [https://php100.wordpress.com/2009/06/26/php-performance- goog...](https://php100.wordpress.com/2009/06/26/php-performance-google/) The article may have changed since then but some of the points are still valid. It also doesn't mention current stable version of PHP (5.3) and still has no mention of bytecode caching. At least it mentions profiling now...

</comment><comment><USER9> This article feels very hastily thrown together.

No mention of APC and they didn't even bothering to discuss profilers beyond a link (which doesn't even return xhprof on the first page!)

The getter/setter thing is the perfect definition of a premature optimization. Making that optimization will result in an infinitesimally small gain compared to what could be had optimizing bad SQL and caching deficiencies.

<comment><USER10> Agreed. Said other bits in another comment, but:

-mysql_query()? BAD GOOGLE WEBMASTER, NO COOKIE FOR YOU. Seriously - there is no good reason not to use PDO, or at least MDB2. (Doctrine is better, but it's just a superset of PDO.)

-References are a modern PHP programmer's (quiet you, stop laughing!) best friend. "Don't use shortened variables because you'll copy data! Just reuse the $_POST['barf']!" Never mind that $foo = &$_POST['barf'] achieves both goals...

<comment><USER8> $foo = $_POST['barf'] does not copy data.

</comment></comment></comment><comment><USER11> This is an old article (2009), which the PHP team has responded to:

"With regards to the new article posted at [URL], all of the advice in it is completely incorrect. We at the PHP team would like to offer some thoughts aimed at debunking these claims, which the author has clearly not verified. "

[http://groups.google.com/group/make-the-web- faster/browse_th...](http://groups.google.com/group/make-the-web- faster/browse_thread/thread/ddfbe82dd80408cc?pli=1)

Previous discussion:

<http://news.ycombinator.com/item?id=676856>

<comment><USER12> Those comments appear to be based on an older version of the page. The current page doesn't have most of those "optimizations."

Edit: And confirmed. See [http://web.archive.org/web/20090628004019/http://code.google...](http://web.archive.org/web/20090628004019/http://code.google.com/speed/articles/optimizing- php.html)

<comment><USER13> The issue of "copy-on-write" ..still here, in addition to the potential SQL Injection vulnerabilities in the sample code.

<comment><USER12> The example they gave ( _$description = strip_tags($_POST['description']);_ ) would trigger copy-on-write, unless I'm mistaken.

And the SQL example isn't meant to be copy/pasted: it's a demonstration of a fairly common anti-pattern that has nothing to do with SQL escaping. Adding escaping there would just confuse the point.

<comment><USER14> The problem, like with all _bad code examples_ , is that people copy and paste it without thinking and don't look back if it runs, so here we are in 2011 with SQLi holes in literally every other website.

Either write a complete, secure example or don't write an example at all. Like a colleague of mine said, putting incomplete code samples on the Internet is like handing out loaded Glocks to children; expect feet and heads to be blown off. I wouldn't even write a toy example with mysql_query anymore because the number of footnotes required (that people would ignore) would fill a page.

</comment></comment></comment></comment></comment><comment><USER15> I recommend Varnish (HTTP cache) where pages are returned instead of touching PHP. APC, a compiled PHP script cache and going to be used in PHP6 releases. Both should lower some resources required.

A lot of bad stuff about PHP in this: <http://www.phpsadness.com/> (Relevant HN discussion: <http://news.ycombinator.com/item?id=2591845>)

</comment><comment><USER16> I guess these are okay suggestions, though a few of them aren't going to make a slow piece of code much faster. Micro optimizations result in micro gains. (On getter/setters, I think their uselessness is better grounds for wiping them out than function call speed, but I digress..)

I particularly dislike the glaring SQL Injection error and not using mysqli in the example. They could have at least used a fake escape_data() function around the values if they don't want to use prepared statements. And ignoring that mysqli_query() would be slow called inside a loop, the solution is taking an n loop to a 2n loop. Ah, if only PHP had inline Python generators to reduce it to one...

<comment><USER17> Using mysqli* functions would still be a "mistake" if you ask me. PDO exists, and gives you all the benefits of mysqli but with relatvely painless cross-DB support.

<comment><USER16> I totally agree that PDO is great. Though I also like the procedural style of mysqli_ functions (don't shoot!). (In Java stuff I have a "object, build yourself from these rows" OOPy pattern.) As for cross-DB support, unless you're using an ORM it's probably going to be painful. Given that some databases conform to ANSI SQL, others (like MySQL) do their own thing, etc., then the issue of built-ins and custom functions (e.g. LucidDB lets you write Java/Jython/Javascript user-defined functions/procedures/transformations) I don't trust any of the SQL strings to work on multiple databases.

PDO's advantage is a standard interface (like JDBC), and if you're planning to ever use more than MySQL with PHP then yes you should use PDO even for MySQL just to get used to the standard.

</comment></comment></comment><comment><USER18> The last optimization is semi-wrong.

From my experience it's faster to make SQL queries in a loop then it is to make one huge SQL query that gets all the data, but requires post-processing in PHP.

Let me clarify:

If you are using all the data from every column and every row, then certainly - do one big query.

But a lot of the time you do code that gets a parent, then all the children.

You only output the parent once. So if you try to write a query that will return all the children at one, you also by necessity are returning the parent data multiple times - yet you only output the parent data once.

To do this typically you store a variable with the previous_parent_id, then check if the new row matches it in your client loop.

Don't do this. It's slower.

Get just the parent data and loop on it, then get the child data in individual queries.

The reason it's faster is database indexes. When you get the parent data you want a sort order - hopefully that column is indexed and the database can return it directly without sorting.

Same for the child data, you want it sorted, you have an index that covers the parent_id, and your sort column and the database can directly return the data to you.

But, if you try to join the parent and child table, only the parent data is pre-sorted. The child data will need to be sorted after the join - often on disk. This is terrible for performance. (The child index is used for the join, but not the sort.)

Additionally you are often transferring lots of data, because you are repeating the parent columns over and over uselessly. That's not free. Even if it's a local database the database server still needs to buffer all that data and so does the client.

Caveat: This is my experience with MySQL, it's possible other databases are able to use indexes to sort both the parent and child records, even through a join.

<comment><USER19> It really depends on the type of query you're making.

If you're talking about a tree, here's how to get a whole sub-tree (as in all descendants of a parent), without fetching parents multiple times, without multiple queries, sorted in a previously defined order and also indexed and really fast: [http://dev.mysql.com/tech-resources/articles/hierarchical- da...](http://dev.mysql.com/tech-resources/articles/hierarchical-data.html)

         When you get the parent data you want a sort order

Not necessarily. People use a sort order mostly to limit the number of rows returned (say you want only the first 50 items with the lowest prices). But optimizing a SELECT using ORDER BY is really hard as there are other restrictions you need to be aware about (like if you're using an index on multiple columns, you can't have a range condition on the first column and sort on the second, at least in MySql).

That's why, if performance is an issue, there are ways to workaround the need to sort -- for example you can keep extra data, like page=1 if position is between 0 and 50, page=2 if position is between 50 and 100, and so on, such that LIMITing the query to the first 50 items is WHERE page=1 (basically storage-efficient precached queries - if the conditions are stable, you can do it).

And in cases where you can't fetch the data efficiently in a single query, you're probably doing it wrong (like you chose the wrong data representation - for example the relational model is really awful for describing anything related to graphs).

Of course, I'm not talking about cases when you're fetching unrelated data or cases where performance doesn't matter or cases when you've got BLOBs in your parent :)

<comment><USER18> You didn't really understand what I meant, which I guess is my fault.

When I say parent I don't mean in the same table, I mean an unrelated parent (1 to many join).

And I use sort all the time without limit, I think it's important for data to always be displayed in a consistent order.

> And in cases where you can't fetch the data efficiently in a single query, > you're probably doing it wrong

Example:

I have a list of buildings, then I have a list of room, then a list of contents.

I want to create a giant page on the website displaying this data. One table for each building, one row for each room, one cell for each content.

You can not get all this data efficiently in a single query.

You can get the data by joining all three tables, but you will be repeating the data about the building over and over for each content.

<comment><USER19> Right, sorry, I misunderstood you.

</comment></comment></comment></comment><comment><USER20> _Avoid writing naive setters and getters_

And let clients manipulate the class properties directly. After all encapsulation is overrated. Best use only global variables.

 _Don't copy variables for no reason_

Forget about the distinction between input and output variables and about readability. Those are overrated too.

The advice in this article is either trivial or wrong.

</comment><comment><USER21> This Article is an very good example how particular correct information can create an biased view.

@google

Please remove the article or replace it with an more accurate and complete one. If you really care about PHP performance to make the world a better place, hire some skilled guys that can help the development of PHP core and libraries. The side effect is that those guys will write better articles.

Thanks.

<comment><USER22> Why do you think so? It it doesn't contain any snide comments. Sure, it is clear that the developers of PHP made some choices that have a negative effect on performance, but so did the Ruby guys. Making tradeoffs that affect performance doesn't necessarily look bad and this article remains neutral as to the background of the performance issues in PHP.

As to hiring developers to work on PHP: I don't see how that would be of benefit to Google. They aren't using it anywhere and I'm sure engineers at Google wouldn't touch PHP with a pitchfork when it comes to selecting a language for a new project. That doesn't mean that PHP is left behind in any way, though, because Facebook and Yahoo are actively working on the PHP ecosystem.

</comment></comment><comment><USER23> So you shave .05 seconds off your PHP execution. Then I have to wait 12 seconds till the page is loaded, because front-end is not optimized at all.

<comment><USER24> No matter how slow the frontend is, the quicker the execution of that script finishes, the quicker that process can handle another request, saving you resources.

<comment><USER23> Properly optimized front-end will help your servers a lot.

Case of typical website: 6-15 JavaScript files, handful of CSS files, tens of images, 60-100 HTTP requests. On repeat visit still the same amount of requests, majority of them are just 304 Not Modified

Case of FE optimized website: 1 request for main document, one for combined and minimized .js, one for combined and compacted .css, 1-4 for CSS sprites files and some content images. Repeated request: 1 request for document (the rest of resources have far future expire time so are not requested). Server has to serve order of magnitude fewer requests.

<comment><USER24> Agreed, but all the static assets shouldn't be served by your application server but either from a completely different machine (or CDN), or at least from a reverse proxy in front of the application server. Aside of eventual port or file handle starvation, serving assets should have no effect on your application server.

So while having one file with all the assets is advantageous for the end users, it should have no or next to no influence on application server performance.

</comment></comment></comment></comment><comment><USER25> > Avoid writing naive setters and getters

You might as well avoid double-quote strings while you are at it.

The test had 1 000 000 iterations which means that you won't gain more than a few micro/miliseconds by doing this.

I would call this advice: naive optimization.

<comment><USER17> Even more troubling to me, is that the author completely ignorss magic methods __get and __set. I ran the two tests he provided locally, as well as an altered version to use __get and __set, and the direct access method, and using magic methods were both roughly 10x the speed of the getName, setName methods.

Even ignoring the performance issue, why would you even consider using an explicit setName over __set ?

<comment><USER26> > why would you even consider using an explicit setName over __set ?

• You don't put logic of all setters in one place. Although you could create some dispatcher in __set that looks up method for the setter and calls it, that's a bit of magic that may not be expected by someone using the class.

• You can control visibility and override setters using standard PHP syntax rather than custom code in __set()

• Inside the class and derived classes it's clear when `$this->foo` is direct access and when it's a setter, otherwise you need to be careful about property declarations and visibility.

• It's possible to pass extra optional arguments to the setter

(none of these points are particularly strong, but there are non-insane reasons to use setters)

</comment></comment></comment><comment><USER27> You know what's much, much faster but no-one will ever recommend?

Globals instead of copying gobs of data between classes.

For example WordPress used to use a global object cache that was passed around by pointer reference. Modern versions now throw around multiple copies of huge gobs of data by copying it back-and-forth over and over again, like all the users and posts and comments on a page. Makes a HUGE performance decrease that is easily measured on complex pages (200-300% slower). If you have frequent cache misses it's quite a workout for the system.

<comment><USER10> Most applications I see just reference-copy.

This article is really, really rudimentary, and not in the good ways. Why does it recommend "not copying data" without explaining references? Why is _Google_ recommending the use of bare mysql_query? I don't care if it's a toy example, they should be reinforcing best practices (or at least not-horrible practices) by using PDO or something similar.

Granted, most PHP programmers I know are not particularly competent. (I am, but I'm also weird enough to be willing to get competent with something like PHP.) But we can at least _try_ to hammer good practices into them.

</comment></comment><comment><USER28> This example:

      $description = strip_tags($_POST['description']);
      echo $description;

      ...

      echo strip_tags($_POST['description']);

Sacrifices readability for performance. Sometimes that's a worthwhile compromise, but often times not. And if you plan on referencing $description more than once (which, most code would), then it wouldn't make much sense to run strip_tags each time.

<comment><USER29> I doubt it even sacrifices performance. The temporary results of strip_tags() still has to be allocated in order to be echo'd out -- so you're using the same amount of memory. $description will be de-allocated as soon as it goes out of scope.

<comment><USER10> Memory cleanup isn't free (the instance of $description in scope), and unless you return by-reference, you're making a double copy.

<comment><USER8> Both versions of the code do exactly the same: 1\. Take description from memory 2\. Allocate string and put the stripped version there 3\. Output the string (here you might save if you don't use output buffering since no copying to the buffer happens but just output) 4\. Release the memory allocated in 2.

<comment><USER10> Whoops, you're right--I was thinking it was getting returned, rather than output.

</comment></comment></comment></comment></comment><comment><USER30> Not trolling, honest question: why is PHP still used? What makes it preferable over alternative server-side technologies? I have programmed PHP before, and I know I could just Google this question, but this kind of search usually turns up rants by language zealots.

<comment><USER31> > Not trolling... I know I could just Google this question, but this kind of > > search usually turns up rants by language zealots.

Isn't that what trolling is?

I'm not sure why that would even provoke rants by language zealots. It's a simple question with a simple answer: big libraries and projects that can't be ported in an afternoon.

That is to say, Haskell is a nice language but there's no Drupal port to Haskell.

<comment><USER30> It's not trolling, look at the excellent answers that I received, including yours.</comment></comment></comment>


Belgian startup Magnax has found a way to mass-produce the axial-flux motor - <AUTHOR> https://spectrum.ieee.org/transportation/alternative-transportation/this-insideout-motor-for-evs-is-power-dense-and-finally-practical <comment><USER2> I am very eager to find out what the price will be for these motors, this will have a huge impact in General Aviation. A banal 4 cylinder 100 HP petrol engine is ~$20,000 ("aviation price") and the weight is a bit over 60 kg, if my math is right a Magnax motor can be as light as 5 kg (even 10 kg is fabulous) but the cost needs to balance the huge price of batteries: the $20,000 petrol engine with 140 liter fuel tanks gives a flight time of almost 10 hours, batteries for that flight time would be insanely expensive and possibly quite heavy. But most people don't fly more than 5-6 hours, so a reduction to 6 hours would be acceptable for 95% of the people.

Another positive impact to GA is you don't need to adjust for mass and balance that much, batteries have a fixed center of gravity that does not change while discharging, while fuel tanks impact the plane's center of gravity as they go from full to empty. Less trimming, simpler flying.

And not the last, it is eliminating any problems with carburetors, mixture, air density or inverted flight: none of these affect an electrical motor, but it needs to be considered for the likes of Cessna where you need to adjust the (fuel/air) mixture depending on the altitude.

And it improves propeller efficiency, simplifying constant speed propeller operation. It can be easily fully automated.

All good news, but seeing it happen is a different story: it can take 3 to 5 years, more that a decade or never to reach mass availability and adoption in general aviation. It has the potential to make the market explode (in the positive way), but there is so much politics involved there are chances the status quo will be maintained. Let's see.

<comment><USER3> I'm absolutely ignorant on the topic of aircraft propulsion, but I'd always assumed that the diminishing mass of fuel that one was carrying around with oneself as the flight progresses is a key advantage that electric-propulsion aircraft can never hope to replicate (short of dropping battery packs with parachutes as they become exhausted of charge).

Am I absolutely wrong or is it not actually much of a factor?

<comment><USER4> I hope to hear actual pilots chiming in, but from first principles:

It shouldn't be a large factor. Drag is independent of mass, and while lifting the fuel to cruising altitude takes energy, most of the flight should ideally be cruising.

The rocket equation doesn't apply; that's for an entirely different regime.

<comment><USER5> While drag is "independent" of mass, the lift required to maintain level flight is affected by weight, and drag is affected by lift. A heavier airplane will absolutely require more power to cruise.

</comment></comment></comment></comment><comment><USER6> Anyone else just impressed by the writing of the article itself? They made a very good effort of providing benefits over traditional radial flux electric motors and how theirs was difference as well as measurable improvement numbers.

I hope they succeed.

<comment><USER7> It reads like an ad to me. It's hard to figure out what the catch is, if any (and in this world of tradeoffs, there usually is a catch).

<comment><USER8> The catch is that radial motors are balanced magnetically and these are not. All that magnetic force is added to axial pull between the stator and rotor. That means they need a thrust bearing in addition to the guide bearings. This causes increased heat and mechanical losses and probably limits efficiency to somewhat less than a standard electric motor. Hi-E standard motors cap out around 98.8%, these will probably cap a point or two lower.

<comment><USER9> I don't have a firm grasp of the article, but isn't the force balanced in this case since the two rotors, linked together, sandwich the stator? If I understood correctly, this would mean the thrust bearing would only feel the imbalance between the two sides.

See: [https://m.youtube.com/watch?feature=youtu.be&v=BTuCshX5bc0&t...](https://m.youtube.com/watch?feature=youtu.be&v=BTuCshX5bc0&t=36)

<comment><USER10> Agreed, this seems to be an incorrect conclusion. Maybe ew6082 just looked at the asymmetrical figure without reading the text.

<comment><USER8> Fair enough. They said that a double rotor version has been developed, but all their prototypes and marketing material are single rotor. We can probably assume that single rotor is all that would fit on an in-wheel design but there are other ways to skin the cat.

They would still need to include a light thrust bearing on the double rotor design since you can never assume perfectly balanced air gap and one side or the other will dominate, but the losses would be much lower with that setup.

</comment></comment></comment></comment></comment></comment><comment><USER11> This is very interesting. And it is very good news that companies are finding higher efficiencies in mass produce-able electric motors. It means that electric cars will become more affordable and practical quicker.

But I do hope they do not proceed with the in wheel concept. In wheel motors make the ride not only bumpier but more dangerous. This is because the wheel with more un-sprung weight bounces more and tends to lose contact with the road more, which in turn makes the car more likely to spin out of control, miss a turn, etc.

Electric cars, being still relatively new, cannot afford to get a reputation for danger.

<comment><USER12> Might work out if it's paired with active suspension.

The idea with motors at the wheel seems to be that the moving parts are all concentrated there. No mechanical distribution. Compartmentalization. But that is not incompatible with active suspension systems.

<comment><USER13> What would be the advantage of doing it that way instead of just putting the motor on the car frame and connecting it to the wheel with a CV axle? From what I could dig up, mechanical losses in a CV axle are on the order of 1%.

An active suspension requires power, too. And a heavier wheel would presumably require a more power-hungry active suspension than a lighter wheel, so you're not getting something for nothing in terms of efficiency.

I guess it is a matter of numbers, though. A CV axle also gives a wheel inertia, as it has mass and moves when the wheel does (partially). If you can make an insanely light motor, maybe you could make it so light that it's actually contributes less inertia than a CV axle would, in which case go ahead.

<comment><USER14> The small diameter of the CV axle makes the inertia small compared to the rest of the wheel, tire, brake assembly.

</comment></comment></comment></comment><comment><USER15> > "If yokeless axial-flux machines replaced only a fraction of the older > machines, we would save our customers some money and make the planet more > livable while we're at it."

The engineering feat is impressive and exciting, but this conclusion doesn't account for the Jevons paradox. In itself, a technical progress that improves the efficiency with which a resource is used doesn't lower the demand for this resource, but instead increases it. The solution to a more livable planet is political, and this is why it's so difficult to find.

<comment><USER16> If you make it cheaper to use a less polluting resource than a more polluting one, this can still work. Improved solar technology, for instance.

<comment><USER17> Yes, but the point GP makes is that you need carrots _and_ sticks. One or the other alone will not be enough.

<comment><USER16> He's claiming that, I guess, but he doesn't actually provide any support. It seems totally possible, depending on the technological specifics, to require zero political coordination.

</comment></comment></comment></comment><comment><USER18> Here is a video of one in operation with some techno music:

[https://www.youtube.com/watch?v=rGu7XDapR58](https://www.youtube.com/watch?v=rGu7XDapR58)

<comment><USER19> That's cool, but I was hoping to find a video detailing the difference in design between axial and radial motors. You know, with exploded 3d models and such. And also with techno music.

<comment><USER20> [https://youtu.be/BTuCshX5bc0?t=36](https://youtu.be/BTuCshX5bc0?t=36)

<comment><USER18> That techno music makes me feel very empowered.

<comment><USER21> I'm sorry to say but that is not techno music at all.

<comment><USER18> What is it called?

</comment></comment></comment></comment></comment></comment><comment><USER22> A concise and technical summary from their blog:

[https://www.magnax.com/magnax-blog/axial-flux-vs-radial- flux...](https://www.magnax.com/magnax-blog/axial-flux-vs-radial- flux.-4-reasons-why-does-axial-flux-machines-deliver-a-higher-power-density)

</comment><comment><USER23> > "One of our designs has a peak power density of around 15 kilowatts per > kilogram. Compare that with today's motors, such as the one in the all- > electric BMW i3, which delivers a peak power density of 3 kW/kg—or just one- > fifth as much. And the Magnax machine is also more efficient."

It will be interesting to see how Moore's law will materialize in EVs. Understanding that the majority of time and effort spent in the automobile industry has been aimed towards combustion engine design as opposed to electric motors, it will be equally interesting to follow the efficiencies to be discovered in the imminent future, taking into consideration how blazing quick they already are today.

<comment><USER24> 15kw is about 9hp/lb. If you can get that maybe you can design a wheel motor that doesn't suck. Two 75 hp motors would weigh about 8 lbs each.

No gear box, differential or CV joints. Potentially really cheep.

</comment></comment><comment><USER25> The most I understand about motors is how they typically work and that innovations are possibly more lucrative than battery innovations; this seems like a major innovation. I must be missing something? What's the healthy skepticism here?

<comment><USER26> Emrax sells this technology for years now. This isn't new, and I couldn't find a datasheet to meaningfully compare them with what else is available on the market.

I do know of axial flux motors that couldn't have had iron teeth, but I think it was a single-side design with a metal backplate to support the resin-soaked stator windings. I recall a nice discussion about them using GaN power electronics to reach very high efficiencies. Those machines were still hand made last year, however...

<comment><USER27> You can, of course, make an ironless axial flux motor with the resin and wire itself acting as a structural composite. Two-sided. I think commonly were used for solar cars (i.e. for student competitions).

<comment><USER26> The prototype I touched was for/part of a 200kW pair (I don't recall if each or total) for a demonstrator plane...

</comment></comment></comment></comment><comment><USER28> > "Motors and motor systems account for approximately 53 percent of global > electricity consumption. We estimate that improving the efficiency of all > the world's motors by just 1 percent would reduce the motors' power > consumption by 94.5 terawatt-hours and shrink their carbon dioxide footprint > by the equivalent of 60 million metric tons."

I find this surprising. Perhaps a big chunk of this is air conditioning, which is technically using a motor to run a compressor?

<comment><USER29> And refrigerators?

<comment><USER30> slight tangent...

Interesting thing to consider is that reverse cycle airconditioners are notoriously inefficient compared to dedicated cooling or heating units..

Reverse cycle units can use anything from 2 times to 5 times the power of a dedicated unit on cooling

<comment><USER31> At least 2 times and as much as 5 times seems surprisingly bad.

Do you have a source or a concrete example for that?

The most plausible explanation I can think of for what you're saying is that you're comparing an evaporative cooling system to a heat pump based one, in which case the 'reverse cycle' aspect is not the thing causing the inefficiency.

</comment></comment></comment></comment><comment><USER7> How much does motor weight matter in a modern long-range EV, vs battery weight?

<comment><USER28> An AC motor for a car might be in the 100-200 pound range or so. DC motors tend to be a little heavier. Along with the motor, you'd need a motor controller and cabling.

Example conversion motors: [https://www.evwest.com/catalog/index.php?cPath=8](https://www.evwest.com/catalog/index.php?cPath=8)

A general rule-of-thumb is that it takes about 100 watt-hours to move a thousand pounds of car one mile. I just started on a project to convert a Mazda RX-8 to electric. That's a 3,000 pound car (before the conversion), and I'm planning to use a Netgain Hyper9 AC motor, which is 120 pounds, which is pretty small compared to the rest of the car (or compared to the original rotary engine). Battery weight is the bigger concern; if I can keep the pack under 400 pounds I'm doing pretty good, and I'll be lucky if that gets me 100 miles of range.

<comment><USER32> According to Magnax no-load losses reduce the effective range of the vehicle by 10% to 20% (iron close to rotating permanent magnets equals braking when there is no load) Magnax claims 85% less iron losses due to the low amount of iron.

</comment></comment></comment><comment><USER33> Awesome design, makes me want to put one together just to see it work. :)

One concern: I saw some designs with the rotor outside the stator, physically mounted to a wheel. I'm not a mechanical engineer, but as a guy who considers himself not quite dumb enough to fail at everything...

I hope they build those motors tough. Typical electric motor mounts create a situation where the only real stresses on the motor are rotational, along the axis of rotation, or in the case of a pulley / gear-mount setup, you are usually limited to 1-2 additional push/pull axis. But on a wheel? That wheel is going to want to rotate and move on all axis, which now needs to be supported by a motor, which also includes permanent electric magnets.

Awesome lighter motor, awesome that we can sandwich the rotor between stators (more layers more torque!).

</comment><comment><USER34> My first thought is that Toyota needs to license this for their hybrids, and mount it on/as the flywheel. Using something like this as either MG1 or both MG1 and MG2 would seriously minify their hybrid drivetrain.

<comment><USER35> Why hybrids, Why not just go for full electric?

<comment><USER34> Because hybrids are the next step until EVs reach the junction of affordable and practical for the average household. Toyota knows this, and is playing it safe until there's a mass-market demand, when they'll step in with the most practical and boring EV possible.

</comment></comment></comment><comment><USER36> There was a lot of ifs, mays and hopefullys in that article, but maybe it's just written in a strange way since it does say they have actually found a way to mass produce this thing. It would be great if true.

One of the first questions that popped into my mind was how would this motor with less mass (less structure) handle 5 times the power/mass of traditional electric motors which are already pretty power full and sometimes break from strain.

</comment><comment><USER37> > One of our designs has a peak power density of around 15 kilowatts per > kilogram. Compare that with today's motors, such as the one in the all- > electric BMW i3, which delivers a peak power density of 3 kW/kg—or just one- > fifth as much. And the Magnax machine is also more efficient.

>We believe that we can scale the design to whatever size carmakers (and other customers) may demand.

Count the weasel words. I'm at 5.

<comment><USER38> Even at 3kw/kg, an electric motors blows ICE out of the water.

<comment><USER37> Not my point, and an electric motor isn't going to do much without a battery.

</comment></comment></comment><comment><USER39> Complex issue. With this innovation they can rethink the whole axel/brakes/rims/hub motor system and perhaps come up with more novel solutions. E.g. Brakes/hubmotor integration to remove the unsprung weight penalty? Rim/hubmotor integration? It's an exciting time.

</comment><comment> mark-r > In tests at the University of Ghent on the first prototype, our yokeless > axial-flux motor reached efficiencies from 91 to 96 percent. And that was > just the prototype.

Wouldn't one expect a prototype to be better than a mass produced unit? It gets individual care and can be optimized for the test.

<comment><USER39> Nah. Prototypes have lots of compromises - wrong materials, crude circuits etc. Maybe bolted to a plywood table top etc. The purpose of a prototype is proof-of-concept and measurement/recording. Not a simulation of real deployment.

</comment></comment><comment><USER40> An electric plane with a motor like this, fueled with hydrogen like Toyota Mirai... seems like it can improve the situation with range?

</comment><comment><USER41> Looks lovely for drones.

<comment><USER26> You get by without the fancy iron teeth mechanical support they invented as long as you remain small enough. The main issue is miniaturizing magnet manufacture without per-magnet costs staying fixed.

I judge by COTS pricing, but the $/kW falling on magnets increases a lot below 5~15kW electrical.

<comment><USER27> Yeah, if you have really tiny rare earth magnets, their cost-per-weight (for a given magnetic energy product) goes up a lot. Just finicky to deal with sintering a bunch of small things, I suppose.

</comment></comment></comment><comment><USER42> But when will we see a motor powered by magneto-reluctance and capacitive diractance instead of the relative motions of conductors and fluxes?

Seriously, though, this article is clear and well-written. I love it when I see people solve problems we didn't know we had. I'd figured we'd basically found the global optimum on electrical motors decades ago and were basically stuck there by physics now, with advances happening elsewhere in the powertrain. This development is like CPU vendors figuring out how to write 3x more single-core performance out of the same thermal budget after our own decade of stagnation in this area.</comment>


Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager - <AUTHOR> https://googleprojectzero.blogspot.com/2019/03/windows-kernel-logic-bug-class-access.html <comment><USER2> It's been a while since I've programmed for Windows but I'm so glad to be away from the LPCS_LONG_SHOUTY_NAMES. It actually kind of hurts my eyes to read this article due to all the normal text/SHOUTY/CamelCase changes.

It would be nice if there was a windows.h replacement that used namespaces, typedefs, enum classes, and bitfield structs to make typesafe non-namespace polluting names for everything while still being compatible with Win32.

<comment><USER3> > It would be nice if there was a windows.h replacement that used namespaces, > typedefs, enum classes, and bitfield structs to make typesafe non-namespace > polluting names for everything while still being compatible with Win32.

I think Microsoft has made too many Win32 wrappers at this point: WinForms, XAML, MFC, UWP... Adding another one isn't likely to succeed. New Windows desktop app development happens in Electron or C#; Win32 is the layer for low- level or legacy apps that aren't going to switch to anything different anyway.

<comment><USER4> You're probably right that applications still using Win32 directly are unlikely to switch to anything new. But the other frameworks you mention seem to be more than just wrappers; they're relatively heavyweight application frameworks that bundle a lot of new functionality rather than just providing a cleaner interface to the core Win32 functionality.

It seems like there should be some appeal in a clean modern Win32 API wrapper that compiles down to almost nothing and doesn't impose design decisions like using XML to define UI layout. That would allow higher-level frameworks like UWP to be implemented in a dialect that isn't so disgustingly arcane.

<comment><USER5> It sound like you want a wrapper that does nothing but change SHOUT to CamelCase. A lot of work to for a developer only cosmetic.

What are you doing in UWP that's arcane?

<comment><USER4> Please read more carefully; I think you missed the point of more than one comment in this thread, so your reply comes across as too dismissive. A modern wrapper around Win32 would offer real advantages beyond just renaming things, such as greater type safety and less namespace pollution.

And I didn't imply that such a thing would have benefits for authors of UWP applications, but for the implementors of UWP itself and other frameworks that build atop raw Win32.</comment></comment></comment></comment></comment>


Toronto's Transit Advice for New York: Give Streetcars Their Own Lanes - <AUTHOR> http://www.nytimes.com/2016/09/08/nyregion/torontos-transit-advice-for-new-york-give-streetcars-their-own-lanes.html?_r=0 <comment><USER2> Manhattan could use a trolley on 42nd and 14th streets. Crossing Manhattan is incredibly slow.</comment>


OS X BSD System Calls Reference - <AUTHOR> http://dyjakan.sigsegv.pl/osx-bsd-syscalls/ <comment><USER2> Seeing all of the syscalls in one place really puts things in perspective. The #ifdef markers are a nice touch, too.

This makes me wonder, what would this look like for plan9? Just FS-related syscalls, and that's it? Curious...

<comment> vezzy-fnord _This makes me wonder, what would this look like for plan9?_

[http://aiju.de/misc/plan9-syscalls](http://aiju.de/misc/plan9-syscalls)

<comment><USER3> i like how the plan9 system calls list can fit on an index card.

I guess that i'm then wondering, to what extent are the profusion of api calls on bsd/linux (by comparison) due to which of the following: a) legacy of evolving richer apis while supporting older ones b) poorer factoring of abstractions c) different special casing for various performance or security related primitives?

</comment></comment></comment><comment><USER4> Note that the BSD system calls do not cover the full functionality of OSX, and the mach interfaces are necessary. For example, sleep() needs to use the Mach message interfaces.

<comment><USER5> Embrace and extend? How is this different to Android vs. the Linux kernel?

<comment><USER6> _" The kernel of NeXTSTEP is based upon the Mach kernel, which was originally developed at Carnegie Mellon University, with additional kernel layers and low-level user space code derived from select parts of BSD."_ [1]

NeXTSTEP became the basis for OS X. It meets the Single UNIX Specification [2].

[1] [https://en.wikipedia.org/wiki/OS_X#History](https://en.wikipedia.org/wiki/OS_X#History)

[2] [https://en.wikipedia.org/wiki/Single_UNIX_Specification#OS_X](https://en.wikipedia.org/wiki/Single_UNIX_Specification#OS_X)

<comment><USER5> That doesn't answer my question.

Both Android and OSX are listed under [https://en.wikipedia.org/wiki/POSIX#Mostly_POSIX- compliant](https://en.wikipedia.org/wiki/POSIX#Mostly_POSIX-compliant)

What I would like to know is, is there any fundamental difference in how the two have derived from their predecessors, ie. Android kernel from the Linux kernel and OSX's XNU kernel from the NexTSTEP/BSD kernels, specifically in terms of compatibility concerns.

(Edit reply to below: Yes but my understanding is that the Android kernel changed fundamental system calls, such as those used for memory allocation, forcing everything userland to be rewritten. Is the 'two systems' of XNU you describe not, therefore, similar in its effect on compatibility?)

<comment><USER4> The Linux kernel has only one set of system calls. Everything you can do with Linux, you can do through it's syscall interface. Android doesn't change this, although it ships a different, more minimal libc.

The OSX kernel has two, due to it's bolt-on nature. Mach message passing and BSD system calls. As far as I am aware, the BSD system calls is an emulation layer, and is not entirely complete.

As a user, you don't care; the quirks of both systems are papered over by libc, which does the appropriate syscall dance to create a posix compliant system. (For an example of a Linux quirk, 'exit()' on Linux doesn't actually exit the process, it only exits the current thread).

</comment></comment></comment></comment></comment><comment><USER7> I heard from somewhere that technically, OS X does not preserve backward compatibility for system calls, so you should use libc function's instead, otherwise it is an undefined behavior. Whereas Linux keeps a hard compatibility guarantee. Is that true? I guess Apple will really hesitate before commiting breaking changes, but I'm genuinely curious if they reserve the rights in thoery.

<comment><USER8> > I heard from somewhere that technically, OS X does not preserve backward > compatibility for system calls, so you should use libc function's instead, > otherwise it is an undefined behavior.

I believe this article[1] definitively answers this as being the case.

> Whereas Linux keeps a hard compatibility guarantee.

Not being a troll here... Why would anyone care unless they are writing a libc replacement? Before anyone objects regarding compatibility with programs written for older versions of OS-X, there have been compatibility libraries distributed for every version I can recall. To wit, I run the Pages app from iWork '09 regularly.

1 - [https://developer.apple.com/library/mac/qa/qa1118/_index.htm...](https://developer.apple.com/library/mac/qa/qa1118/_index.html)

<comment><USER9> > Not being a troll here... Why would anyone care unless they are writing a > libc replacement?

Statically compiling the libc is common with proprietary Linux software, if I remember correctly.

<comment><USER8> Gotcha. I guess it's an OS expectation thing then. In OS-X, it's pretty much an assumption that dynamic linking is what's going to happen (good or bad).

Thanks for clarifying this point for me.

<comment><USER9> Linux userland has various libcs available (klibc, glibc, eglibc, uclibc, dietlibc, musl, …), with distributions occasionally switching between them, and ABI-incompatible changes happen every once in a while. Source-distributed software does not have to care usually, but for binary-only distribution, statically compiling the libc is the easiest bet. Thus, the kernel _has_ to maintain compatibility.

</comment></comment></comment></comment></comment><comment><USER10> Linux's syscalls: [http://man7.org/linux/man- pages/dir_section_2.html](http://man7.org/linux/man-pages/dir_section_2.html)

(I have learned a lot by just going to that page and randomly clicking on things.)

<comment><USER11> This is documentation. It's not an ABI reference the same way the article is. The article is about the nuts and bolts of how user mode makes calls into the kernel, which manpages don't bother with.

If you want to learn the syscall ABI on Linux you need to look at <asm/unistd.h>. Seems like this file has gone through some refactorings since the last time I looked, but here's an older version: [http://lxr.free- electrons.com/source/include/asm-generic/uni...](http://lxr.free- electrons.com/source/include/asm-generic/unistd.h?v=3.2) [edit: ia32 here [http://lxr.free- electrons.com/source/arch/x86/include/asm/un...](http://lxr.free- electrons.com/source/arch/x86/include/asm/unistd_32.h?v=3.2)] -- the constants in the __NR_* macros define the table that this article is attempting to build. [Basically, the interrupt handler for a syscall needs to know where to jump based on that index.]

</comment></comment><comment><USER12> Why so many duplicates? For expample int nosys() is listed 185 times, each pointing to bsd/kern/subr_xxx.c

<comment><USER11> Because when you remove items from that list or otherwise change the order, you break binary compatibility.

The C library specifies the index into this table when making a syscall. You don't want a situation where the C library and the kernel are mismatched and disagree about what the syscalls are.

The safe way to remove a syscall is to change it to return ENOSYS. All the syscalls that come after it in the table therefore retain the same index.</comment></comment>


PANDAcap: A framework for streamlining the capture of PANDA execution traces - <AUTHOR> https://github.com/vusec/pandacap <comment><USER2> Can someone kindly explain what this is used for?</comment>