Does this, like SGX, require signing by AMD itself?
This is a major letdown for SGX adoption, making it essentially useless for anyone but maybe niche markets trying to protect IP on cloud services.
If a master key COULD be loaded by the OS early at boot time (and cannot be replaced until CPU reset), it would be incredibly useful to create software-based TPM services that provide trusted isolation where needed.
It seems as if intel/amd are doing this 'just because die space is cheap, and why not try "ip-protection-as-a-service"' instead of a truly generic solution.
The trivial "safe" C++ linked list prevents you from dereferencing uninitialized memory, leaking resources and performing incorrect type conversions, which are the typical issues you'll find in any C linked-list implementation. But there's no compile-time check for the actual lifetime of the objects. This means you can manually destruct the same object twice, for example, and the compiler will not warn.
RAII can get you /very/ close, but since it's not enforced at the compiler level, Rust guarantee is definitely stronger.
My main point is that the strong guarantee comes also at a significant complexity cost, and I'm still not sold it's worth it in many conditions.
I'm absolutely for safety and compile-time assurance. I wrote I've actually use ATS in embedded systems where I could to perform compile-time theorem proving. I used ATS, for example, to actually prove at compile-time the runtime heap memory requirements. This is not easy.
Rust is not on the front of research here, although the borrow checker is more pleasant to use compared to /many/ other implementations.
Memory safety is, of course, important, but security as a whole is so much more than just pointer dereferencing and lifetime checking. We got pretty far with C++, modern toolchains and OS support. Rust programs will be only marginally more secure by default than other classes of programs. Rust will not help with entire classes of other problems like side-channel attacks, any logical bug (like incorrect initialization of IVs, unchecked reflection), and so on.
Rust helps, and I do not criticize that. But as with any system, you have to evaluate it as a whole. Is it a big boost coming from C? Absolutely. C++? Not so much. Heck, you can use LuaJIT in embedded systems, and Rust has zero advantage there.
I gave Rust several trials in the last year, but I somehow ended up thinking that it's [maybe too much] hyped. Rust managed to get quite a bit of traction.
I've been programming in Haskell and Python in the last years, but I've done more of a decade with C++ only and lately begun some MCU work where I had to use C++ almost exclusively again. I don't have a strict preference anymore, although I edge in Python for new projects as it strikes a good balance.
I'm quite familiar with runtime type checking (hs), and hey, I've actually wrote a couple of programs in ATS (whose syntax is absolutely horrid, and second only to the compiler warnings), because ATS essentially translates to C without an extra compiler, allowing you to use it for any MCU supported by your toolchain.
I came out thinking that doing seemingly simple stuff in Rust, such a mutable linked list, is too complicated for what you get. Let's be honest here, writing a safe linked list in C++ (even more so with C++14) is _trivial_, despite C++ being anything but simple to understand as a whole.
This is aggravating if you think that in systems programming, mutable state is almost central to performance (caches and locality). Most of the efficient structures you end up writing are ad-hoc, mutable and with manual memory layout. Complicated code is a double edged sword: if I need to write complicated code to get compile-time insurance, it means that it's a trade-off to just jumping into unsafe territory where the payoff is small.
I somehow like the syntax of rust, but it's quite verbose. Almost too much in places. And I compare this to C++, which is not too skinny either. But C++ got much better lately. I also really don't like how rust inherited the JS style of wrapping closures directly as arguments of functions (think unwrap). It really reads horribly. I'd have vouched for dedicated syntax for such a common idiom. C-like languages (and C++ included) do not read as nicely as homoiconic languages in these cases.
If writing simpler code leads to less bugs, then Nim is actually a much better language. I wish it had more mindshare, as the core and language itself is far from being polished and regular as rust currently is. The current premise of compile-time safety of rust is good, but not a dealbreaker if you use a modern C++ compiler IMHO. It's pretty easy to wrap unsafe behavior in a class. It's actually easier than wrapping unsafe code in rust.
I never understood this argument about rST. The syntax for the same MD features in rST is only /marginally/ different, certainly not harder. I use both, depending on the context (which forces me to use one or the other). Most of the time you don't even notice the difference, because both have a really good baseline.
However MD falls short for writing technical documentation, which is why pretty much anyone has to dope the "standard" (GH flavored MD, and so on). The syntax for the extensions is not any better than what rST offers. rST generally allows a more human-readable writing style, whereas MD with extensions has a lot of very verbose inline formatting.
In fact, rST CAN have a slight edge in my mind as a human readable document if you use the appropriate formatting, whereas MD with extensions is easier for a program to parse.
But, I repeat myself, for the same set of MD features, rST is hardly different. If you don't believe this, use pandoc and try to transform a vanilla MD document into rST.
Now pick any rST page from sphinx documentation, and move back to MD. Hardly any better. sphinx is often criticized for being "hard to write" or illegible, transferring the blame to rST, but for the same set of formatting MD is not better. sphinx allows a whole slew of extra features which require a lot of annotation, and MD doesn't save the day.
What's really annoying if having to switch between the two. We have projects which have a good majority of text documents written in MD and then API references in rST. I hate that. There's constant mismatch.
I'm also running 4.6.4 (arch). This particular issue was incredibly bad when we got the first models (tearing at the mouse position) and progressively improved, but it's still not fixed.
Note that the modesetting drivers also incur in several performance hits compared to the regular xorg-video-intel. For instance, I can see libreoffice dialogs REPAINT, while inkscape works at 1/4 of the refresh speed.
This is not lenovo specific though. Intel drivers typically lag 1-2 years behind current models at the time you can consider them "bug free enough". This was true for any laptop I've been using the last 10 years.
I cannot fathom how broken the skylake driver is right now.
Sigh... another big hope of mine. I have a Carbon X1 (3rd gen), thankfully a company laptop.
I'm quite disappointed by it, and I was hoping to push our company to move over the XPS line.
We got the HD display with touch screen. Although it's a decent display, there's substantial glare. In fact, scrub the useless touch and get the matte, which also boosts the brightness a little bit. Not to mention, the laptop is so light that attempting to touch the display will just flip the laptop. This is my first "not antiglade" display since the CRT era, and I regret it a lot.
After several months of usage, the display developed several uneven backlighting issues (some spots are quite bright), and I noticed the black is not as black anymore compared to an unused one (we have 24 of them with several to spare). We moved from the HP EliteBook series (which also has their issues), and while the contrast is much better than any elitebook I've used, we never had uneven backlighting with HP.
The keyboard was a big issue, and I see that XPS does not realize how important it is. In fairness, the X1 keyboard is not too bad, except for the awful placement of the Home/End keys. No squeaking and decent feedback. But the small keys such as the arrow keys work very poorly. The rubber dome behind them is so small that if you don't press the key with some little extra force it will "pop" but not activate. In particular, this is especially bad for the up arrow, which of the 24 laptops we have was horrifying. If you use bash, remember the up arrow is "recall history". The problem is that the key is slightly slated (for "ergonomics"), causing the dome to be pressed unevenly. I fixed mine by some careful placement of scotch, but it's still not the same accuracy of other keys.
The trackpad is awful for some reason. HP was much better here. No amount of tweaking would allow me to perform fine movements.
Battery life is the same on both linux and windows (around 7 hours new for random workload), so no complaints here. Power management works. But, the HP EliteBook G4 we where using before has a super-easy replaceable battery, and we changed many over the years. The G4 is around 6 hours of battery runtime. Not much difference honestly. Not to mention the G4 is very easily serviceable.
On linux I still have problems with the intel drivers with the carbon. The "old" drivers work, but the modesetting drivers cause "twitching" of the image especially on the second external output. Incredibly annoying to the point that I'm still using the legacy one. This is a classic issue with intel, and unfortunately it's the same for any laptop nowdays.
Overall, the display is still a bit better than whan HP offers, but the rest is worse. The laptop is a bit thinner and lighter, but honestly there's not much difference here. The appreciated the serviceability of the HP line as components started to fail. Although opening an X1 is not hard, there's not much you can swap without replacing the entire laptop.
True, but in practice nobody really has a reason to override the title bar, because it forces you to implement dragging and resizing behavior as well. People that do this know the pain. It also works poorly unless you do it at a pretty low level (within the toolkit itself).
The only program(s) that do this are chromium and firefox in my machine, and both can disable this because it doesn't look native.
Client-side decorations, visible in the screenshot, are a true PITA. It's stupid that each widget set has to replicate this behavior. It results in visual differences, and it's doubly stupid that this is touted as an "advancement" just for the rate case that you want to override the title bar.
You could have done the inverse, as currently done with X11 (server-side decoration by default, but overridable).
This incurs in stupid behavior for all tiling window managers in wayland, as they cannot enforce the client to remove the title bar. For a tiling window manager user, this a significant downgrade in wayland. The WM protocol in X11 is one of the few areas that let X11 innovate a lot compared to all other desktops. The number of (wonderfully) different window managers is proof. Server-side decorations, in particular, should have been a no-brainer!
I started with amiga, windows (from 3.1 to 2000) and I've been using Linux as my main development and OS since more than 10 years now. I no longer use any other OS. I consider myself lucky I basically never interact with windows anymore. For the cross-os work that I have to do, python with qt covers me to the point that I just perform final testing. Amazing.
I used OSX around 10.4 for about four years, because it seemed like the best of both worlds: nice UX with an unix backend. That is, indeed, why OSX appealed to most geeks, right?
I became tired of OSX after a couple of years. What apple dictates might look good, but it's far from functional. It's eye candy with little substance. On the surface is pretty, but Finder under OSX was essentially a crapshot. Under Linux I could have virtual desktops, but not under OSX (that only arrived years later). Tweaking, even slightly, any default behavior is hard. That is also the reason why Gnome doesn't appeal to me. The basic OSX desktop doesn't offer anything beyond a current Gnome release. Things change if you need commercial programs, but the desktop itself is not inferior in both behavior, looks and general interaction. Gnome is, performance wise, slower, but the people that use gnome do not seem to notice.
Not to mention that what every developer does on OSX is install an external package manager, and by and large replace every single userland utility and library with an up-to-date variant from Brew, MacPorts, etc. This was a massive burden. Any linux distribution is far superior in that regard.
I don't think that Gnome today is far away from OSX. Sometimes OSX is smoother, sometimes Gnome actually is.
But, my desktop today is nowhere even remotely comparable to what gnome offers. I'm using a tiling window manager with pretty much any program customized to the point of being unrecognizable. It's incredibly efficient compared to a pretty desktop. I'm aggressively disabling eye candy and animations everywhere. I'm often using CLI versions of GUI programs because the actual user interface is superior. Some TUI programs have no rivals in GUI form.
The fact is, is that if you use your computer professionally and switch to linux, you start to understand what user interface efficiency is. At some point, eye candy becomes a second, third, fourth priority. This doesn't mean the program is any less usable though. I still value presentation. I'll take a nice UI any day over a crappy one, given the interaction is the same.
I've witnessed the same happening to many people that I've suggested linux. Many of those still use windows or mac, but with completely different habits.
As far as technical documentation does, the python documentation is usually ranging from pretty good to very good.