Hacker Newsnew | past | comments | ask | show | jobs | submit | thomasmarton's commentslogin

While not a dump per se, there is an API where you can get HN data programmatically, no scraping needed.

https://github.com/HackerNews/API

reply


I still remember the early days of this pay for blue check system when Biden was talking about man parts while being indistinguishable from the real account


Wasn't Microsoft the "let's not break backwards compatibility for any reason" company?

Coming from software development, we do have tests that insert a screenshot into the report in case they fail, and I'm assuming we are not the only ones that found the PrtScr button to be useful for that


> I'm assuming we are not the only ones that found the PrtScr button to be useful for that

I can honestly say you might be the only ones. I've never heard or even conceived of such a thing.

There are a ton of ways to avoid this in the first place:

- use CLI to take the screenshot instead of simulating a key press

- don't test on Windows 11

- use reproducible test instances where you've turned this option off

- (if screenshotting text) use... logs?

I'm truly baffled by this complaint.


If they’re programmatically pressing the PrtScr button, then hopefully it’s not too difficult to write or find a library that takes a screenshot too.


You're saying you have tests that programmatically "press" PrtScr to take a screenshot?

I wouldn't put it past Microsoft to preserve the old behavior just for programmatic keypresses.


Then disable the new default behaviour, by using the provided setting?

For 99.999% of the users, I reckon this is a good change. And for the rest they've thoughtfully provided an option to revert.


That ship has sailed with Windows 8 and .NET Core reboot.


Oblig xkcd https://xkcd.com/1172/


This is basically Microsoft's big chance to create Docker for windows. Prebaked images on top of this lightweight layer and shared folders which are already supported.

I'd love to see this happen on environments where you need Windows, but you still want the ease of deployment feature of Docker


Docker and containerization is something that already exists for the Windows kernel though.

https://learn.microsoft.com/en-us/virtualization/windowscont...


I hella learned something new. I'll be sure to look into this after work. Thank you!


Except Docker containers doesn't actually run on Windows as they do on Linux (Linux containers that is, I don't know how Windows containers does it). What Docker Desktop does is creating a WSL VM for running your containers, which is basically what everyone did before as well (on both macOS and Windows), but with a easier setup.


Windows Containers are a Windows-native container solution. No Linux kernel need be involved. This lives alongside Linux VM-based containers in Docker Desktop. Obviously you can only run Windows-based images, which confuses people that think Containers=linux. I think BSD has a similar concept as well. https://wiki.freebsd.org/Docker


Yeah, that's what I would have guessed. Fortunately (unfortunately for some?), most containers are Linux-based, both for deployment and development purposes.


Docker does support launching Windows containers both local and Hyper-V backed. Windows has a feature called Silos which allows linux style isolation.


It's beyond an equivalent to a Docker container because it includes kernel isolation. This is a security distinction that isn't well understood.


At least on Windows, Hyper-V isolated containers are also a supported feature, which should also ensure kernel isolation. I assume Kata containers or any other virtualization backed solution would give you similar guarantees.


It is a different thing.

They point of containers is that they do share the same kernel, and that each container is just a different namespace.

If each entity has a different kernel, they are VMs. VMs can be also pretty thin and have shared immutable store for their base image, but they are not containers anymore. Similarly, Xen DOM-Us are also VMs.


This feels like an opportunity for Microsoft to start finally cutting out legacy cruft. Guarantee a 100% pre-Windows 12 seamless emulation layer. Once that is established, it becomes more possible to port to ARM, RISC, or make foundational breaking API changes that have been desired for decades.


Then watch as people reject the new APIs and continue to develop for that emulation layer.


Win32: "I have slain many a challenger; you won't be the last."


That's true. Win32 has been undefeated.


yep, and they'll complain the entire time saying Microsoft never does anything new.

this has happened a couple times, really.


That was the plan for Windows 10X, this would’ve been used as a Win32 compatibility layer. But that plan was killed (hardware compatibility?) and the UI was ported to regular Windows 10 to make Windows 11.

https://www.theverge.com/2020/2/11/21132822/microsoft-window...


Windows containers for docker exist for a long time already, they are even compatible with k8s. And they are just a mess. Windows is not really a suitable platform for containerized apps.

If you want a sandboxed App environment for windows, there are the UWP/Store apps, which are also not that great.

I have the feeling that Microsoft kind of gave up on windows and is trying to move everything into the cloud and the browser.


Whats erong with UWP/ store apps?


they should give up on windows too.


I think that’s what they are doing. Most new sever side products they release have first class Linux support. And most new desktop applications are web based. Also Edge is supported on Linux.


Azure runs on Windows.

https://techcommunity.microsoft.com/t5/windows-os-platform-b...


And Linux - every Azure blade has an embedded ARM SoC running a hardened Linux with various daemons that interface with both the Azure backend and the Windows host, control offloading of network and storage processing to the FPGA, and other tasks.


Those are probably hyper-v hosts. Yes it is Windows, but it’s mostly a virtualization platform for running VMs.


At least their managed Postgres service is running on Windows machines. I don’t know much about Azure but after seeing that I’m pretty convinced that most services they offer run on a Windows kernel.


Many of their PaaS platforms are controlled by Service Fabric running on Windows. For example, Azure SQL Managed Instance is in this category. You can see the "SF" paths in a few places.

I've been learning a bit about Service Fabric recently. It seems to predate Kubernetes and appears to scale far higher because it has native support for partitioning large clusters by "tenant id hash" or similar keys.


It doesn't matter, it is a Windows flavour still.


And give up their internal expertize with the stack?


At this point we could even deviate from software development and say this about any job that requires thinking and decision making around a set of rules.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: