Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Wild Penquin

  • Content Count

  • Joined

  • Last visited


This user doesn't have any awards

1 Follower

About Wild Penquin

  • Title

Profile Information

  • Gender
  • Location


  • CPU
  • Motherboard
    Asus Maximus VII Gene
  • RAM
  • GPU
    EVGA GTX 970 (04G-P4-3975-KR)
  • Case
    Lian Li DX-04
  • Storage
  • PSU
    Works and is silent
  • Display(s)
    Samsung LC34F791
  • Cooling
  • Keyboard
    Corsair K95RGB Platinum
  • Mouse
    Logitech G703
  • Sound
    Jazz, Progressive Rock, electronic music!
  • Operating System
    Arch Linux

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well, this is only partially correct. There are standards for hardware, among controlling fan speed, but these are not always followed. It is not just the fan speed that has standards. Linux as an OS, will need someone to write drivers for non-standard hardware. This can be really difficult if the manufacturers either don't do it themself or release the specification for someone else to do it (=volunteers!). Unfortunately, laptops (or, their manufacturers) are notorious for making their devices non-standard, and only releasing closed-source drivers for their (not users) choice of OS. Sometimes reverse-engineering is needed to get even basic stuff working. Luckily, sometimes they release closed-source drivers for Linux, sometimes even Open Source some part(s) of their drivers. Macbook Pros are not especially well supported on the manufacturers part. That being said, distributions could make life easier for users and automate installation for setting up Laptops and possibly some other more exotic hardware. Often the case is, there is some small third-party (open sourced or closed source) utility to add missing functionality which is not there OOTB. Generally, they don't, since there are limited volunteers and diminishing returns for the needed work to support every piece of hardware out there... so some manual work from the user is needed. Think of Linux (or OpenBSD or any Open Source, free OS) as if you were building a house from stuff you get from the HW store; you will need to do some work yourself. There will always be some manual work for Open Source OSes (unless someone makes some kind of paid distribution / service, which will give enough incentive for someone else to polish the experience for the end user!). p.s.: on my Macbook Pro, in addition to fan speed control, I also needed to 1) find the right Wireless driver - and the closed source driver just stopped working after a recent update, 2) add SysRq support (re-map key configuration on Kernel level), 3) install ReFind (there could have been other solutions but this was easiest) and 4) tweak the Touchpad to my liking. With default drivers it's just way too buggy for two-finger scroll, which is a must for my workflow, and 5) tweak the way screen brightness was set, sine aalthough it was working, it was not working 100% well (not all of the range was in use). Possibly something else I forgot.
  2. Well, on my old MBP from 2009, IIRC on OS X it way way more quiet than on Linux (and while CPU was quite hot, it didn't throttle), but in Linux without fan control, the fan would spin at 100% no matter the load (problem: this is unbearably loud). So I needed fan control in Linux just to get a reasonable noise level from the Macbook. So in my case, it is converse to OPs situation (but different model MacBook Pro). So I agree, fan control is needed. In any case, it should not be a surprise you need fan control (and other tweaks) on an OS not supported by the manufacturer...
  3. Another good read is this: http://write.flossmanuals.net/command-line/introduction/
  4. It should work with or without quotes. So either: MAKEFLAGS="-j6" or MAKEFLAGS=-j6 Should be fine (quotes are necessary if you have spaces, say adding several MAKEFLAGS; and with that rationale the quotes are more clean or correct, because it will be easier to add flags later if needed). Some programs might compile / parallelize worse than others, some might have some weird (non-standard) way to call make or compiling the source and drop the MAKEFLAGS variable set in /etc/makepkg.conf. In that case you could try to fix the PKGBUILD. IMO it is a bad habit to set MAKEFLAGS in the PKGBUILD (unless there are specific reasons to do so); Usually they are system specific and should be set on the host system.
  5. In that case, ITheSpazI already linked the instructions.
  6. Nice that you got it working! Just a few things (for future and people eavesdropping): Partition entries (numbers) have nothing to do with the actual order they are on the disk (has been like this on MSDOS type partition tables IIRC and still is on GPT). The number which will be assigned, will be the first free number (but I suppose a partition utility could assign any free number, but this is what they will usually do). If you delete and add partitions, you might end up with any kind of partition numbers and their orders. But it is nothing to worry about, as it irrelevant what numbers the partitions are given; generally, it is not recommended to rely on them (or even disk device nodes) in any case, but use partition or FS UUIDs. Moreover, GUI partition utilities might not give all relevant information. For example, the listing in OP does not state where a partition starts and ends - it only gives their sizes. They could be in order (they are on the disk), but this is only an assumption, and not a safe one (say, you want to resize a partition - it might be more difficult than anticipated). Best to use command line (since those are DE agnostic and same for all, and even work for example if your DE fails) or figure out how to get more information out of that GUI thing, whatever it is (perhaps there is an option to display more columns with more information?). To answer your original question: the approach is to make sure GRUB does not have anything on the previous Linux installation. It is possible it is installed that way, in case the installation was left over from your previous Linux installation. Most Linux distributions will install their bootloader, unless specified otherwise - so usually the one which was installed last will be "in charge". Lukyp outlined what is needed. You can do this from the already booted Linux installation (no need to bind mount nor chroot).
  7. Any live Linux, chroot and then passwd (please ask if you don't know what this means). Unless the hard disk is encrypted, there is no (real) protection on any computer, if a user has physical access to it. A re-install is a good (better!) option, too. You won't have any cruft left from the previous owner. Who knows, there might be rootkits already installed (either on purpose or by accident from the previous owner). EDIT: Also, you might want to free Linus Sebastian from that laptop. Otherwise, we will get no new videos from LTT anymore! EDIT2: If the laptop has a bootloader, such as grub, with some way to access Kernel boot parameters (and it is not disabled on purpose), it is quite easy to boot into a single-user =root session without the password being ever aked.
  8. Yes, clamav will do the trick and is probably what the OP needs. I'm not aware of any alternatives (probably because clamav does it's job good enough, is free and open source - and in such a case, it makes little sense to divide development efforts into separate projects). About viruses in general: There have been little viruses for Linux. The most probable reason is that Linux (or OS X) is a less popular OS. It makes sense for virus writers to target popular OSes of the time (such as DOS and Windows). Also, Linux is/has been protected by more computer-literate users, who are less likely to fall into "stupid mistakes", say dialog boxes on web sites etc.; and are more likely to be able to spot viruses and be prepared for them. Also, Linux as an OS (at least pre-Windows XP) was much better protected against virus infections (although, it can not be stressed enough: it was never immune. The protection comes only from more clearer the separation of Kernel | user-space | permission system of the OS FS). But: the protection from rarity and more-computer-literate user space might diminish, as a OS becomes more popular (and possibly the average user is not that computer literate as before). Usually (at least historically) Viruses have not (usually!) migrated from an OS to another. But this is not a "safe" assumption; it has been like this only because it has been convenient from the viruses point of view (or their developers). It is certainly possible to write a OS-agnostic virus (even across architectures, I'd assume it is more easier though if the CPU architecture is the same - which used to protect OS X users). There more and more common factors between OSes, such as web browsers, and common scripted languages (Javascript and the like) which might run OS-agnostic viruses. Also there are file formats, which are borderline (or actual) programming languages in their own right, and could (at least in theory) contain a virus. One good example is MS Word macro viruses, and these are OS agnostic at least to a certain degree. Also, it is possible a Windows virus will run in Wine (in OS X or a Linux desktop environment). It will still see a Windows machine, but it doesn't mean it can not corrupt the users files (depends on how Wine is/was configured, but 99% of the time it has full R/W support to the users home dir who is running Wine). There's one important point, though: just because a Virus could not run on your OS, doesn't mean it is desirable to share viruses from files you got elsewhere for your peers (who might run another OS). That's why it is a bit naïve to claim there are no scanners targeting viruses made for another OS than on which they are running. There is a clear need, and there have (pratically) always been virus scanners for "other" OSes, especially on non-Desktop-only oriented OSes (clamav runs on many OSes, btw).
  9. This probably boils down into Laptop manufacturers not giving information about their devices (or better yet, actually supporting Linux). In worst case, the touchpad is non-standard. There is no way for the drivers to know what to expect from such a touchpad... Anyways, run in (a terminal) 'xinput list'. Is your touchpad listed there? If yes, then try 'xinput list-props X' (just the number should be enough) and try to figure out how to use xinput to make the touchpad behave. I can't give specific instructions from the top of my head, but perhaps this will point you in the right direction :-) I needed to do some tweaks with xinput for my MBP (though, it was nowhere near as bad as what you describe), but for multi-touch, the default Synaptics was just unacceptable. I got better results with libinput. If xinput does not help, you might try to look for instructions to how to switch to libinput instead (of Synaptics ... it get's a bit hairy, xinput is a tool to configure either under X.org). It might work better (or not) with libinput (worth a shot). There are some google hits with "linux touchpad sensitivity" which might be relevant.
  10. I did a Google search I think you could do this with xbindkeys and xte. See: https://askubuntu.com/questions/624756/how-can-i-map-keyboard-buttons-to-my-mouse-buttons You can bind any mouse key (or key+mouse combination) to trigger pretty much anything (command, script, keystrokes). With xte you can even fake any keystroke. Long answer and some thoughts (about the lack of a GUI options and other stuff): If you want someone to implement a GUI option for this (from your wording I'm not sure are you asking for help or someone to make this option into the GUI, which you already know doesn't exist), then I think you are on the wrong forum. Better place is the official forum for the DE or Distro you want the feature implemented on, or better yet, a feature request on the appropriate bugzilla. You need to invest some time in making a good feature request, and rationalize why the features you want to implement are needed and/or are a priority, if you ever wish them to come into fruition (i.e. give good examples of use cases and problems that a proposed feature would fix). A tool to do what you want does (possibly?) not exist just because it makes no sense to most people. You are probably trying the wrong approach to some other problem; can you be more specific, why do you want to do this; what is your use case? What you are trying to achieve? The behavior of mouse keys should be (ideally) defined higher on the software stack (software should react to the mouse key events the way the user wants). But, sometimes software does not have the features you need ... so I can see that what you need might come usefull. But it is a corner case! After all, they are a different (physical) keys, and even separate devices. Conclusion: as this is a corner case, it it should not be a GUI option in the first place, at least not in the core GUI of the DE; that should be left to more common use cases, since if every users (special) needs would be covered, options will grow exponentially, which will make the GUI quite a mess eventually. So this seems like a job for a user script or for third party tools (such as xbindkeys/xte and others; someone could of course write a frontend GUI for a certain use case!). But scripts and command line utilities will always be more versatile than a feasible GUI can be - for this kind of task! This is a classic example of "right tool for right job". [/long answer]
  11. Wild Penquin

    where to install grub

    UEFI or Legacy? With UEFI, you might 1) not use Grub at all or 2) Install Grub on the EFI partition. Don't use Legacy if your computer is recent enough to use UEFI. If you really need to use Legacy, it doesn't really matter where you install Grub. Grub itself is quite agnostic. It makes sense to install it on the HD which has the Linux distribution, somehow (one obvious benefit is that if a HD fails, you will have a more intact setup, possibly...)
  12. Yes, you are correct. It is not sending any more information From the Google search I conclude this is just as I said; it's meant to be a convenience feature to add your system information to Github GIST, which you can easily link to whenever asking for help on forums or discussing stuff. Of course, it all boils down to if you trust the people who are making the distribution. Any Linux distribution could be sending information without the users consent, either intentionally or unintentionally. Mint is quite popular and has a lot of users, some who are quite tech savvy. That is something which can protect you - if it was sending stuff without users content, someone would notice (sooner or later, probably sooner), and there would be a huge outcry if that happened.
  13. So, it is in some System Information -dialog where you found this. From this it should be clear that it is system HW information what it is sending. However, it is certainly not clear where it is sent to and why. Also the information it sents is more verbose than shown in the dialog. Google search comes up with this: https://community.linuxmint.com/idea/view/6616 Also, google finds some issues about the button not working in Github. I presume it is something to help the user to upload the setups system information to display e.g. on forums etc. when asking for help. I could be wrong, though. This is something that definitely could be improved, since it doesn't fill the principles I outlined before (and these are also mentioned in the community suggestion I linked above). It is not a huge deal, IMO, since it doesn't send anything unless the user clicks the button. Even then it doesn't intentionally send anything that is private (although hostname etc. are considered private information by many)! Best place to discuss this is the Mint Forums. That way also devs might (finally) improve it, as outlined in the suggestion. Is there anything mentioned about the feature in Mint documentation?
  14. Where is this button, actually? Screenshot? As already said, there is nothing wrong in gathering information if the user is told what and when is collected (and where it is sent, and what it is used for etc.). It should be clear from context what the button does, and to whom it sents the information.
  15. You can not damage HW, physically, unless it is badly designed and does something non-standard. There was the case (don't remember brand and/or models) that had bad, incomplete UEFI implementation, which could be bricked by a Linux distribution which tried to install itself in UEFI mode alongside Windows. Their BIOS would just hang, and there was no way of doing a HW reset. Sucks, and the manufacturer was to blame. Google can find it, too lazy to do it now (EDIT: Looked for it anyways, could have sworn it was Acer, but seems it affected some Samsung models instead). In theory, some badly implemented feature on a motherboard could be misinterpreted by FOSS software so that something could get damaged, say, due to overheating (fans being constantly off etc.). Or, similarly to the bad UEFI implementation, something being stored to the non-volatile Flash memory in a modern Laptop - but in these cases, it is more like a design fault on the manufacturers part IMHO.