It's funny you mention that. I grew up with the Windows API first and then moved to Tcl/To, and then Swing. I remember wishing I could just manually position things instead of packing into horizontal and vertical boxes. Maybe it is Stockholm syndrome with the Windows API for me.
That's interesting, but do you connect those Librettos to the internet to use mIRC? Sounds a bit scary with Windows 98 in 2017. I wonder how a newer BSD or Linux would run on it with say BitchX or some similar older irc client.
You could say that as developers "age out" (by becoming managers, moving to other industries) of the development world that this cycle will repeat itself over and over.
This is missing a lot of BSDs. Now granted some of them are dead, some inactive, some just missing. The ones I can think of off the top of my head: PC-BSD/TruOS, MirBSD/MirOS, Bitrig, HardenedBSD.
It's mostly hardware support still. As an example, try using a Baytrail/CherryTrail laptop with Windows 10. Now try in Ubuntu. Oh you need Linux 4.11. Oh that's not out yet, so you need to run a bleeding edge kernel directly from git. Even Ubuntu 17.04 is supposed to ship with 4.10 so you'll have to wait until Ubuntu 17.10 before your hardware might be usable.
So basically just a blog that creates lists. We see this a bit too often on YouTube. I am not sure we need more boingboing/BuzzFeed style of blog spam..
The OpenBSD team runs coverity on their LibreSSL fork and continues to improve the codebase constantly. More distributions are switching to LibreSSL too.
It sorta does. It's just we use the packaging tools of the operating system (like apt-get and equivalent tools on other systems). That and pkg-config solves 99% of the problem on Unix-based systems. Windows on the other hand... Good luck.
This is just not true. If you've ever worked remote and need to work through a problem there is nothing faster then getting on the phone and doing a screen share just as if you were face to face.
There's really only one thing I dislike about pgsql. It seems overly difficult to return two disjointed result sets from a stored procedure/function. This is fairly common and easy in MSSQL. It also is easy in MySQL. Something like this:
SELECT int_col_1, int_col_2
FROM table1
SELECT varchar_1, varchar_2, int_col_2
FROM table2
In pgsql if the columns are the same type and number then we can use a union, otherwise the suggested alternative seems to be to just make 2 queries.
It's not necessarily hard but it is a ton of work and requires a lot of low level knowledge of the underlying window system. You need to have a very good understanding of the layer beneath you (xlib, Wayland, win32) and how fonts are rendered on the various systems you want to support. There's also various tradeoffs you need to make. Do you go with custom drawn widgets or use native ones? Native offers a shortcut if you have a greater understanding of the lower system API. Custom drawn requires possibly less knowledge of the various widget API but more knowledge of the underlying window drawing API. Getting basic buttons and labels drawn is not hard. The harder parts are menus, text entry, scroll bars and scrolling. None of the current toolkits were cross platform from initial release. Almost all started with Xlib and then years later were ported to Windows. Some still haven't made the port to OSX (except to rely on x11). It's a lot of work and maybe that's what makes it hard.
Rust seems very complex and C is more about simplicity (in the sense that K&R is a short read). Other languages with the same spirit of simplicity would be Tcl and perhaps Go. I just wish Go had more supported machine architectures.
OpenBSD, FreeBSD, and NetBSD all have support for the older Apple G4 and G5 hardware. Obviously being older they are kind of slow (especially compared to amd64) but if you just use them as file servers they are fine. The biggest problem with BSD on PowerPC, in my opinion, is the lack of modern programming languages. I believe on BSD you are stuck with C, C++, ruby, python, and perl mostly. No node, no Java, no golang, no rust. If you use Debian you have access to Java.
Maybe not $15k but developers frequently have much more powerful (and thereby more expensive machines) than the users who use those apps. Many of the developer machines at work have 16 to 24 gb of ram, SSDs and very fast CPUs. Our customers on the the hand might be running machines with a non SSD drive and 4gb of ram (or less??).
Yes this is correct. I looked into doing this to see if it was possible to use Tk with the Jim interpreter. It's probably possible but would be a significant investment of time. Tk has some deep integration into Tcl internals.
This really depends on what your production environment requires. LibreSSL is mostly API compatible with OpenSSL but removes FIPS and support for esoteric platforms. If your production environment requires Windows 3.1 or big endian amd64 then probably LibreSSL is not ready for your production environment. Seriously though some of us are already using LibreSSL in production without problems.
I thought that Trump's idea (Scenario 4?) was to raise the import/tariff fee so that it would essentially cost the same regardless of where it was manufactured. Another option would be to eliminate things like NAFTA. I'm not saying these are good ideas (in fact they may be terrible), I just want to point out additional scenarios.
I've come to the conclusion that one should "use C++ when they absolutely have to and C when you can." There just aren't many areas where C++ is absolutely required when plain old simple C can be used. (Not to mention using higher languages if possible).