I did that with 2009 thinkpad and it got much worse. I guess the cheap paste I used was worse than the 6 year old paste lenovo had used :(
What _did_ help was to take out the fan, clean it and then oil it carefully (too much oil or doing so without cleaning it first will only make things worse). You can also buy replacement fans, although original fans are quite expensive.
> ... I find the boot time compelling enough (~23sec until login, plus 2sec to open the browser) that I do not need this.
I think something is slowing down your boot, I get faster boot on a 2008 thinkpad running the same OS.
OT: systemd was supposed to improve boot performance but it has actually become much worse. Upstart on a weak chromebook boots in under 2 sec, why shouldn't your current generation thinkpad with a fast SSD match that?
I find it curious that you care about boot-times. I use macbooks and just close and reopen the lid. Waking from this sleep takes less than a second usually.
My average uptime is about 22 days until I reboot for an update or something.
I used Linux for years, and I understood that in 2008 sleep/resume on notebooks didn't properly work, but now we have 2017 - 9 years later!
I don't really care about boot times, but as a tech guy 23 seconds sounds like an error to me and I want to find it and fix it :)
Also, old laptops with dieing batteries (or new ones with always-on sensors such as fingerprint readers) have some leakage during sleep so it may be better to turn them off if you are not going to use them for a few days.
edit: resume/suspend in linux works just fine and has done so for many years (in response to eltoozero)
...which is crucial since you don't want to lose your data when closing the lid. (Non-tech-term is on purpose here, since users shouldn't need to know about the difference. Also I believe OSX uses a hybrid approach).
According to a comment in the post it fails when the swap partition is encrypted. However why enable swap with 16 GB of RAM? I've been running without swap for almost 3 years and never had any trouble. If I start approaching the limit I'll buy another 16 GB.
Exactly, the comment in your blog is "suspension to disk does not work if your swap partition is encrypted. This is due to how Ubuntu encrypts your home (ecryptfs) but not due to Linux itself."
I use whole drive encryption to protect data in the event I leave my old X220 (Fedora) on the bus.
I don't mind boot times in the 20s range (X220/Fedora/cheapo SSD) too much, but I do need to close down/reboot a couple of times a day otherwise no point in encryption.
> but I do need to close down/reboot a couple of times a day otherwise no point in encryption.
Given, I'm not a Linux user, but I don't understand this at all.
On Windows, encrypted is encrypted-- the lock screen is exactly as secure as the login screen. Are you saying that in Linux the lock screen is easily-bypassed? So you have to keep your computer logged-out when you're in a place it might get stolen?
Wasn't there a recent story about how Windows is storing keys so that it can wake up in the middle of the night and apply updates? I thought that the conclusion was that locked isn't as secure as logged out.
What I'm not understanding is why logging out or rebooting is required to keep a computer with full disk encryption secure. That's certainly not the case on competing OSes like Windows.
Usually in Linux the system is installed on an encrypted filesystem (cryptsetup, LUKS). Only kernel and so called initrd image (early boot stuff) is outside the encryption. The disk is opened at very early stage in boot when just about the kernel is loaded. Thus, the encryption is open whenever the operating system is running. Everything is of course still transparently encrypted on disk but the "lock" is open. One must shut down the computer to close the filesystem's encryption.
"Then click Install Now, and follow the rest of the instructions until you get to the “Who are you?” page. Make sure to choose a strong password — if someone steals your laptop while it’s suspended, this password is all that comes between the attacker and your data. And make sure that “Require my password to log in” is checked, and that “Log in automatically” is not checked. There is no reason to check “Encrypt my home folder” here, because you’re already encrypting your entire disk."
Above quote is from the section titled 'How to encrypt your disk in Linux' on the page at
Would be nice to have a faster one, yes :) ... some recommendations?
Just fyi: I measure boot time from the time I press the power button. The BIOS logo appears a staggering 8sec or something although the BIOS fast boot is enabled. (Maybe the sync with NSA or something ;))
8 seconds for the BIOS sounds ridiculous; that should take less than a second. Check that you've booted and shut down successfully on the prior boot; with those, the boot should take much less time. (On an improper shutdown, the BIOS may do some extra work that takes longer.) Also check that you don't have some option enabled to make it wait around a while for a keyboard key.
For the Linux portion of your boot, try running "systemd-analyze plot > /tmp/boot.svg" and looking at that. (Also note that "kernel" includes any time spent waiting in the initramfs for you to type your disk encryption passphrase.)
Unsurprisingly UEFI didn't change much about vendor firmware shittiness. There's also still firmware around which just takes 5-10 seconds of black screen before doing shit.
The initial boot delay is VERY annoying. I wish libreboot was supported on my laptop, then I could ditch lenovos ancient BIOS (and the NSA ping) once and for all:
Different people have different needs. This laptop despite its minor flaws was in the end the best option for his particular needs
...or as a HN user said a while back:
tuananh 42 days ago | parent [-] | on: Why the MacBook Pro Is Limited to 16GB of RAM
all of this largely depends on personal preference.
to me, i value battery so much more.
it seems when people recommends stuff that has many flaws like this, it seems they set the standard pretty low and i find it hard to take the recommendation.
I don't understand why it is limited to 255 chars. The kernel copies the string(s) into the programs memory so it would be a kernel bug if the program got a non null-terminated or too long string.
More importantly this program has a bug in that it doesn't check if there is an argument passed to it at all.
Good effort but can improve a lot. I would praise the documentation but it is rather imprecise. All in all i wouldn't put it on the front page of HN yet.
This is great feedback, which I plan to use to improve the echo program. I'm just learning (on my own), and I figured I would just post my progress and I would get some feedback; it worked!
echo is far from finished, and it's safe to say "I don't know what the hell I'm doing", but hey, I gotta start somewhere.
Maybe the 255-char limit is a feature? If this "fast echo" is meant to be used in a script that writes entries to a log where you wouldn't want long text anyway, or something like that... So having a known upper bound for the output size can be useful.
> I don't understand why it is limited to 255 chars. The kernel copies the string(s) into the programs memory so it would be a kernel bug if the program got a non null-terminated or too long string.
But you can also pass arguments to execve(2) which are not null-terminated.
The kernel copies the strings you pass in the array of pointers. (haven't checked though, but it is better then the alternative of not copying and dealing with the mess)
Maybe only a few pages remain as programs don't inherit memory from their parents. It could be done for those strings but consider that mappings are in 4k pages (so the rest of the page would have to be cleared to 0).
Serious answer: Because many developers regard assembly as some sort deep magic only understood by elder gods.
This, of course, comes from some vague (and not entirely correct) understanding of "assembly" running beneath everything else, and thus being fundamental, yet not immediately useful to a large category of developers today. Hence it seems important but archaic. Archaic + difficult = elder knowledge.
I've actually had a few coworkers think I'm some sort of elder god when I find the root cause of subtle bugs that would've either required deep knowledge of the C++ standard, or not-as-deep knowledge of Asm. These are bugs that others have spent many hours staring at the source and stepping through in a debugger without any better idea of why they occur, but are solved in minutes by a glance at the Asm. IMHO if you are working with native code at all, it's a very useful skill to have.
Even though it was a bit of a "sufferance", I enjoy having been full circle somehow. Starting with Java OOP in college, then went lisp maniac [1], then ml/FP. Which were all somehow further away from the machine, in a way. But at the same time lisp model seems a fairly thin layer over raw asm. And you realize that primitives of computing: arithmetic, logic, iterations.. are very similar whatever the language or paradigm. I then learned a bit about continuation, non determinism, compilation and now I'm almost free. A language is mostly an encoding. Most of them speak about the same things but in a different clothing.
Not 100% free, I think I need to finish my compiler training and forth bootstraping before I can claim that.
I can't really suggest others to follow the lisp, ml, prolog road though, so I'll just state what I wrote above.
[1] SICP especially, with its gradual pedagogy. From substitution, to environment, to register machines. You can see the relationships up close.
From my experience most of the hard to trace errors come from uninitialized variables and they are usually valgrindable. It is VM-based so it can cache jumps and other conditions that depend one uninitialized vars via taint analysis.
Yes. From experience, many developers, namely newly-graduated college students from not-so-rigorous programs, have little idea of Assembly. The same applies with theoretical computer science (Turing Machines, FSMs, PDAs etc.), algorithmic analysis and fundamentals of computing hardware (flip-flops, half/full adders, basic CPU design).
The X1 does not offer docking stations nor does it offer the port range that a T460s offers (full ethernet, card reader, etc). The T460s is a few mm thicker than the X1 and about 200g heavier, but it shares a lot of hardware with and can use the same dock as the X260, T460 and T460p which is interesting if you're a business customer that wants to support a range of options from ultra-portable to powerful.
If you're a single freelance person or consumer, the X1 may be the more appealing choice.
OT: Krita and others are doing great things for content creators who want to use FOSS.
BUT most of their work is lost to us due to the way distros handle external software. If you install Krita, gimp, darktable in debian you will get really ancient versions (unless you use a PPA from a mostly unknown source, but even then you can get quite old versions).
While Pino is busy packaging Krita 3.1.1 for Debian, you can easily run the latest Krita by getting the official appimages that I prepare myself. (Being the Krita maintainer and project lead.)
Thank you, I was hoping to get an answer like this!
I also noticed that 3.1.1 is available on ubuntu snap. At this point I am not sure if I should go with snap or appimage. Either way, it is great to get packages directly from the developers!
Chrome has its own deb repository -- maybe more active projects need this too. (Maybe there's a service to be had hosting and configuring repos?)
I'm on Xubuntu 16.4 and I have 2.9.7 installed. I missed the entire year of developments. 16.10 has 2.9.11 released Feb 4th. 17.4 has 3.1.1 but won't be released for ~4 months. Maybe we should blame Ubuntu for 6 month release cycles, or me for not upgrading, but regardless of the cause, Krita users don't have the new version.
> we should blame Ubuntu for 6 month release cycles
16.04 and onward can now have apps decoupled from the OS release for apps that provide snaps, like Krita does. `snap install krita` will get you 3.1.1.
Isn't that more dependent on your distro than anything else? On openSUSE Leap 42.2, my default is 3.0.1.1, and I could add the less-tested but realistically fine KDE:Extra repository for the latest version. Fedora seems to be shipping 3.1.1 as well. Arch and openSUSE Tumbleweed are also on 3.1.1.
> BUT most of their work is lost to us due to the way distros handle external software.
Distributions put a lot of work into making sure that software they package is managed and handled in a way that their users like. Your example, Debian, is a distribution that favours stability above all else -- so is it a surprise that features are not merged into packages that often? There are many distributions (openSUSE Tumbleweed, Antegros, Arch Linux) that are far more rolling release and have newer packages.
If you want new software, use a distribution that gives you what you want. Don't blame the distribution for providing what the majority of its users (and community) want.
As far as I can tell, they are "fat" distribution packages which are independent (within reason, I guess) of the Linux distro. The aim seems to be to get rid of dependency hell and dependency on exact Linux distro versions, at the cost of larger packages. They also sandbox the app. I'm not sure I understand the disadvantages, besides the larger package size due to redundant libraries.
The motivation is pretty weak. If people found a way to make money by doing this, it would be massively exploited. But the reward for breaking a bunch of phones is... self satisfaction? ok.
I don't know that people were seriously making money on most of the script kiddie shit that was going on on the internet back before ransomware and bitcoin and such (other than AV vendors), and yet it was rampant anyway. I imagine there are still people out there who do this sort of thing "for the lulz".
I'm not so sure. Nowadays they can focus their energies on profitable activities like ransomware or adware. If you're going to break the law to cause grief anyway, why not make some money while you're at it?
You can quite easily purchase unlimited outbound SMS from just about any local carrier in any part of the world for less than $20, either one time or monthly.
It would be very easy to mass message this to an entire country in a matter of weeks.
Messages on the mac can be automated with applescript.
tell application "Messages"
send "This is an iMessage" to buddy "foo@bar.com" of (service 1 whose service type is iMessage)
send "This is an SMS" to buddy "+1234567890" of service "SMS"
end tell
What _did_ help was to take out the fan, clean it and then oil it carefully (too much oil or doing so without cleaning it first will only make things worse). You can also buy replacement fans, although original fans are quite expensive.