0 users browsing Discussion. | 17 bots
| Duck Penis |
Posted on 19-02-01, 19:25 (revision 1)
|
|
Stirrer of Shit
Post: #11 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Posted by tomman Right, I forget. That's true, but as long as it works it works. I think you pretty much have to be insane to want to work with this anyway. It's true, there are some people who do genuinely appear to doing it, but they are also the kind of people you would specifically want not to be developing a web browser, arguably fitting into that category. Which means you have two categories of people: those who do it because they enjoy web "technology", and those who do it because they're paid to do it. I mean, I wouldn't want to work on developing the kind of web browser that I'd like to use. HTML and anything related to that is a big can of worms Which leaves you with two options, either scavenging parts other people built for money and hoping the "commercial pressures" parts are neatly separated, or hoping insane people work on making new ones. As for minimalist UI, I do genuinely mean it. As in, there is no user interface at all:
The only buttons are the OS' minimize, maximize, close. As you might be able to guess, it does not have any kind of extension support since it's just a very small wrapper around the engine. I tried downloading it and trying it out, and it turns out the idiots dynamically linked it, so I can't run it with my version of glibc and would have to download several hundreds of megabytes of dependencies. It must be the vaunted "easier dependency management" that comes from dynamic linking. Posted by tomman If it's just a rendering engine, I don't see the problem. In theory, it should force them to dial down the insanity just a notch for it to be bearable to use on weaker devices. Posted by Kawa You've just managed to describe two applications I hate. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| Screwtape |
Posted on 19-02-02, 06:59 (revision 1)
|
|
Full mod
 Post: #103 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
Posted by tomman Also, Blink and Webkit might be legally distinct, but they're technically still very close. It's like getting to choose between a 10mm ring spanner and a 10mm open spanner. Also... ugh, Discourse. Really, Mozilla?! You had to pick which is probably the WORST forum software package in earth? Discourse is great. Normies get their fancy JS-heavy animated UI, and techies can use RSS and email without even touching a browser, even without a GUI. Posted by sureanem New versions of glibc use versioned symbols to support binaries built against old versions of glibc, so I'm guessing you're deliberately sticking with an old or hyper-conservative distro to avoid change in general or to avoid particular changes you don't like. It's a free country and you're perfectly welcome to use whatever version of glibc you like, but as general advice, you'll live a happier life if you can avoid getting angry at other people over the consequences of your personal choices. The ending of the words is ALMSIVI. |
| Duck Penis |
Posted on 19-02-02, 13:21
|
|
Stirrer of Shit
Post: #12 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Posted by Screwtape It's not great at all. Why should I have to use email to read a regular forum? Why can't they just use any of the plenty of forum softwares which have existed since the 90's? Why couldn't they make it work without JS, like Reddit, 4chan, phpBB, and many other websites do without any problems at all? Posted by Screwtape I'm running Debian stable, which is a perfectly standard distribution. It is neither old nor hyper-conservative. I have glibc 2.24, which was released on 2016-08-05. No other application has had this issue. Clearly, they are the ones in the wrong here for writing software that depends on running untested beta software to even start. My "personal choices" are not outside of the envelope. Just what is it that was added in the last two and a half years that didn't exist in the C standard library before anyway? To my knowledge, the last revision was in 2011, which was 7-8 years ago - far before my "old version" was released. And if they want to rely on nonstandard features, why can't they link them in themselves and write portable code? See, this is why I don't like Rust and why I don't like dynamic linking. Nothing but trouble. And for what? Saving a few kilobytes of binary size, that promptly get consumed by the bloated "standard library" you use? There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| Screwtape |
Posted on 19-02-03, 07:26
|
|
Full mod
Post: #104 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
Posted by sureanem Why should I have to use 90s technology to read a forum when it can be made to work with 80s technology? Besides which, typical forum software (including this forum) is very wasteful and inefficient, labelling each post with an author and an avatar and a posting date and a permalink and all kinds of junk that most people don't care about 90% of the time, just because without some kind of client-side scripting it's not possible to have it show and hide. Also, you wind up with a bunch of posts concatenated vertically so you have to scroll past the ones you're not interested in instead of just hitting the 'next unread' key, and because there's so much wasted space you typically only get 10-20 posts per page, instead of being able to look at all of them and pick out the most-interesting ones. Don't get me wrong, webforums and imageboards have their charm, and foster interesting micro-cultures that wouldn't crop up anywhere else, so I don't want to *destroy* them. But it's not practical for a medium or large organisation to get anything done in a webforum. Why couldn't they make it work without JS, like Reddit, 4chan, phpBB, and many other websites do without any problems at all? Are you sure Reddit works without JS? I think Reddit uses even more JS than Discourse, or at least New Reddit feels a lot more sluggish and swapping-heavy than Discourse. I'm running Debian stable, which is a perfectly standard distribution. It is neither old nor hyper-conservative. My apologies, I shouldn't have assumed. Debian Stable is perfectly respectable and not hype-conservative, although the release process for the next stable version has already started, so the current stable is a *little* bit old. I have glibc 2.24, which was released on 2016-08-05. No other application has had this issue. Clearly, they are the ones in the wrong here for writing software that depends on running untested beta software to even start. As a counter-point, I recently switched my automated higan builds from Debian Stable to Ubuntu LTS because Stable's glibc was too old for a syscall byuu wanted to use (getentropy(), added in 2.25) and because Stable's gcc was too old for the compiler features byuu wanted to use (C++17). So yes, other applications do have problems with glibc 2.24. It's also unfair to say that versions of glibc newer than 2.24 are "untested beta software"; since then, glibc has had five stable releases: 2.25 through 2.29, tested by the glibc maintainers and in other distributions. Even if glibc is untested beta software, Servo is itself relatively untested beta software (number of official stable releases: 0) so it seems unfair to complain about the binaries of a project that expects most users to be actively developing and building from source. Just what is it that was added in the last two and a half years that didn't exist in the C standard library before anyway? To my knowledge, the last revision was in 2011, which was 7-8 years ago - far before my "old version" was released. And if they want to rely on nonstandard features, why can't they link them in themselves and write portable code? You *do* know that glibc is responsible for the kernel API as well as the C standard library, right? And that the kernel adds new, more efficient API calls every so often, and glibc exposes them to userspace directly, or re-implements existing functions to be more efficient. There's a certain noble minimalism in writing code that would work perfectly on UNIX Sixth Edition on a PDP-11, but it's not the One Correct Path. Especially for a project that (like Servo) is trying to experiment with making maximal use of modern graphics hardware, rather than being portable to an ASR33. If portability helps them access and try out more modern graphics hardware, like on Android or iOS devices, then that's good. More portability than that, like supporting old graphics hardware, or old OSs with old drivers, is bad for Servo because that's effort that doesn't benefit their primary experiment-with-modern-graphics-hardware goal. See, this is why I don't like Rust and why I don't like dynamic linking. Nothing but trouble. And for what? Saving a few kilobytes of binary size, that promptly get consumed by the bloated "standard library" you use? Static linking is awesome, until there's a security fix for OpenSSL and you have to redownload (or recompile) half your OS install. And then again next week for the next security fix. That said, Rust supports static linking perfectly well, it's just a bad idea most of the time. Many operating systems only provide their APIs as dynamic libraries (including Windows and macOS) so you can't build a static binary there. While you *can* statically link binaries for Linux, it's a bad idea on a glibc-based distribution because some authentication-related features depend on dynamically loading authentication plugins. If you know the app doesn't use any of those features, then go ahead, but it's not a safe default. If you really don't like dynamic linking, you might look into Alpine Linux, which uses musl-libc rather than glibc and I think promotes static linking. The ending of the words is ALMSIVI. |
| wareya |
Posted on 19-02-03, 07:52
|
 Post: #41 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Insert note that rust static links normal dependencies by default. |
| Duck Penis |
Posted on 19-02-03, 16:07
|
|
Stirrer of Shit
Post: #13 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Posted by Screwtape It's perfectly feasible to make it autohide via CSS or so, but it doesn't really serve a point. Unless you're browsing on a phone (in which case they get moved to above the post for that particular reason), you have plenty of free space off to the side. Generally, this would just be used for a large margin, since it's not very comfortable to read text spanning the entire width of your monitor. So you might as well put some post information there. Discourse has the tiny, round, soulless avatars, and wastes the infinitely more precious vertical space instead. But yes, better forum software does away with it and just has a thin line on the top with name, date, post number, and menu. As for posts per page, this has been configurable on almost all board software I've ever used, this being a noticeable exception. As I recall, on many boards there's a "jump to last post" button, which calculates which page it's on and links to /threadX/pageY#lastPostID. Anyhow, it's not something you'd need JS to implement. The limit in posts per page isn't technological either, it's just an arbitrary default. Imageboards show the whole thread in one page without having any issues. Posted by Screwtape I don't see why they wouldn't work for large organizations. If GitHub would go ahead and replace the "Issues" view with phpBB, would there be any noticeable changes but the theme? Or rather, why is Discourse better than regular forum software? Linux uses mailing lists which are arguably even more primitive and they still get things done. Posted by Screwtape Yeah, the new reddit doesn't work without JS. Old reddit can't handle collapsing posts without it, even though it's a simple change. It can still render posts, something which Discourse fails at due to transmitting them over XHR. Why?! It adds to the load time of the page for no good reason. Posted by Screwtape A little bit, yeah, but hardly ancient. Posted by Screwtape Fair enough. I'd still make sure to statically link in the getentropy() wrapper, since a build dependency is much less severe than a runtime dependency, but I guess it's a matter of opinion. Posted by Screwtape I still think it's a bad idea. The binary is 306 MB big, and they can't be bothered to link in the standard library which is only about 527k (musl) or 7.9MB (glibc)? Posted by Screwtape Right, I forget that it doesn't only deal with funny GNU extensions. It could be a new kernel feature, but then why are they introducing hard dependencies on fairly recent kernel versions? They're writing for Windows too, and presumably they want their browser to work on older kernel versions (cough Android) And it can't be the latter, or else it wouldn't be a hard dependency. As for the use of modern graphics hardware, isn't the goal of Servo to eventually replace Gecko? Is it intended to just drop support for anything older than Windows 10? The portability I'm asking for isn't anything insane like running on a PDP-11, it's that the binary releases should be easier to use than the source releases. If everyone's expected to build it themselves anyway, and the binary builds are broken, then why even release them? Might as well tell people to piss off and build it themselves if they want it so much. Posted by Screwtape You forget that static linking isn't the only one with security issues. How many security flaws have there been from LD_PRELOAD again? Also remember that the only thing that would need to be changed in such a scenario is the library version, it wouldn't be an update proper and wouldn't take much space to download. It's true that Windows depends on the Win32 library. But that doesn't prevent your from statically linking in everything else. On Windows systems is probably where I've had the most use out of static linking, since you can download wget or ffmpeg or whatnot and have an .exe file ready to run without having to find ten random .dll files first. Yeah, there's also Morpheus and Void. It's a very cool concept, but I also want stable software I don't want to update. In practice, debian wins out, as flawed as it is. The ideal would be a Debian-based distro with apt, with all the packages statically linked using musl and apt set up to not be as trigger-happy with the "recommended software". Also sane defaults, like shipping with a moderately sane vim and bashrc, /var/ on tmpfs, "last used" and similar spyware removed, and application set small enough to always be in RAM like in DSL. Ah, a man can dream... There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| Nicholas Steel |
Posted on 19-02-04, 04:15 (revision 1)
|
|
Post: #102 of 426
Since: 10-30-18 Last post: 499 days Last view: 14 days |
Posted by sureanem Wouldn't that break if users have different number of posts per page configured and share a link between each other? AMD Ryzen 3700X | MSI Gamer Geforce 1070Ti 8GB | 16GB 3600MHz DDR4 RAM | ASUS Crosshair VIII Hero (WiFi) Motherboard | Windows 10 x64 |
| CaptainJistuce |
Posted on 19-02-04, 05:27
|
|
Custom title here
 Post: #221 of 1164 Since: 10-30-18 Last post: 63 days Last view: 12 hours |
Posted by sureanem Can't we? I clicked "Edit profile" up top, and I see options for "Threads per page" and "Posts per page". --- In UTF-16, where available. --- |
| Nicholas Steel |
Posted on 19-02-04, 07:21
|
|
Post: #103 of 426
Since: 10-30-18 Last post: 499 days Last view: 14 days |
https://www.bleepingcomputer.com/news/software/mozilla-halts-firefox-65-rollout-due-to-insecure-certificate-errors/ There are reports that Mozilla has withdrawn Firefox 65.0 because the current release is Causing Certificate Errors for people who use certain antimalware packages like Avast, AVG, and Kaspersky. The relevant security companies are working with Mozilla to release updates that will resolve this issue. AMD Ryzen 3700X | MSI Gamer Geforce 1070Ti 8GB | 16GB 3600MHz DDR4 RAM | ASUS Crosshair VIII Hero (WiFi) Motherboard | Windows 10 x64 |
| CaptainJistuce |
Posted on 19-02-04, 08:34 (revision 1)
|
|
Custom title here
Post: #223 of 1164 Since: 10-30-18 Last post: 63 days Last view: 12 hours |
Posted by Nicholas Steel "Mozilla halts Firefox 65 rollout because users are upset that Firefox tells them when they are the subject of a man-in-the-middle attack" Or alternative: "Mozilla halts Firefox 65 rollout because it completely ignores the system certificate store and this unsurprisingly causes issues." From the article: "By default, Firefox 65 will use only use the certificates in their built in browser certificate store. It is possible, though, to enable the ability to also use the antivirus engine's certificate that are created in the Windows certificate store to validate other web sites certificates." --- In UTF-16, where available. --- |
| Screwtape |
Posted on 19-02-04, 12:46
|
|
Full mod
Post: #105 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
Posted by sureanem CSS technically allows things to auto-hide, but doesn't really provide the kind of nuanced interface that native apps and JS can provide. For example, I can click a menu name to reveal the menu then click a menu item, or I can mouse-down on the menu name, drag to the item I want, then release. CSS only really lets you expose information on-hover, and that gets really frustrating really quickly. I'd also disagree with "there's space to the left and right, so you might as well put some information there". That's clutter - give me the most important information, but don't show anything more unless I ask. Discourse has the tiny, round, soulless avatars, and wastes the infinitely more precious vertical space instead. Eh, one person's "wasted vertical space" is another person's "easy to navigate even while scrolling at top speed". The limit in posts per page isn't technological either, it's just an arbitrary default. Imageboards show the whole thread in one page without having any issues. Imageboards can show hundreds of posts on a page because they generally don't do any kind of formatting, just spitting out left-aligned blobs of unformatted text for the browser to stack vertically. Most actual forums try to make the page look a bit nicer by sticking things into a table, and they have to interpret fancy BBCode or whatever. That gets expensive - annoying on modern hardware, prohibitive on the 90s hardware most forums were designed for. I don't see why they wouldn't work for large organizations. If GitHub would go ahead and replace the "Issues" view with phpBB, would there be any noticeable changes but the theme? Or rather, why is Discourse better than regular forum software? If GitHub replaced their "Issues" view with phpBB, there'd be rioting within six hours, if only because issue-management relies on tagging and searching and phpBB's search is utter bollocks. Discourse is better than other forums because the front page of a Discourse instance shows you what's been happening recently in the community, rather than immediately forcing you to decide between development/support/general/off-topic categories. Discourse is better than other forums because when you go to write a reply, instead of giving you a big box to type in and a little window to review the previous comments, which are probably formatted differently and in a different order, you get a little (but resizable!) box to type in and the original thread is still visible behind it, looking exactly like it did before you hit Reply, so you can easily find the bits you wanted to talk about. Discourse is better than other forums because you can paste an image into the message-compose box, rather than having to find a third-party image host, upload the image, and figure out what crazy syntax this particular forum uses for inline images on an external host. Discourse is better than other forums because when post #297 quotes post #13, there's an automatic link back so the reader can see the full context without having to go hunting for where the quote came from. Also, the quoted post gets a link *forward* to the quoting post. Discourse is better than other forums because when a thread gets necro-bumped, it puts a little marker just before the bumping post saying "7 months later" or however long the gap is. There's so many reasons Discourse is more pleasant to use than phpBB, but it's not about any particular feature. Fundamentally, phpBB and other 90s forums said "a forum that's comfortable for humans is hard to implement for computers, so we'll compromise and make a forum that's only a little bit awkward for everybody." Discourse just set out to make a forum that's comfortable for humans, no matter how hard to implement it would be. Linux uses mailing lists which are arguably even more primitive and they still get things done. The thing about LKML is that there's already a pretty big barrier to entry in the form of "having to understand the Linux kernel", so requiring people to learn mailing-list etiquette isn't that much more of a hurdle. That definitely would *not* work for internal communication in a company or a charity or something, where most people aren't 30-40 year old nerds. There's also a good argument to be made that the rigid culture around the LKML excludes a bunch of talented people who would otherwise help make Linux even better. So even if Linux still "gets things done", maybe they'd get more things done if they used different communications infrastructure. But regardless, Discourse *is* a mailing list, so it's got that covered too. :) Fair enough. I'd still make sure to statically link in the getentropy() wrapper, since a build dependency is much less severe than a runtime dependency, but I guess it's a matter of opinion. The getentropy() wrapper basically *is* glibc. I guess somebody could write their own wrapper around syscall(3) with all the architecture-specific variations of type, alignment, and offset for the arguments, but it'd be a lot easier to just statically link glibc. I still think it's a bad idea. The binary is 306 MB big, and they can't be bothered to link in the standard library which is only about 527k (musl) or 7.9MB (glibc)? It's nothing to do with file-size, it's all about developer time. How many glibc assumptions would be broken by linking with musl? How many dynamic-linking assumptions would be broken by linking dynamically? If any weirdness does crop up, how difficult will it be to diagnose the problem, how difficult will it be to work around, how many problems will the workarounds cause? How many extra contributors will we get by supporting older Linux distros? It's *likely* there'd be no problems enabling static linking, but there's a risk, and very little reward if any. Therefore, it's safer to leave things as they are. Right, I forget that it doesn't only deal with funny GNU extensions. It could be a new kernel feature, but then why are they introducing hard dependencies on fairly recent kernel versions? They're writing for Windows too, and presumably they want their browser to work on older kernel versions (cough Android) When you say "they", do you mean the Servo developers, or the glibc developers? Servo just links with the current version of glibc, and when glibc supports multiple ABIs for a given symbol, the linker picks the newest one. Sometimes glibc adds a new API for a new syscall, and that obviously requires the corresponding version of glibc. Sometimes glibc makes an existing API use a different syscall, for efficiency or reliability reasons. For example, older versions of Linux provided a syscall to implement gettimeofday(), newer versions of Linux map a memory page containing that information into every process, so gettimeofday() is now a pointer-dereference instead of a syscall. The glibc API is the same, but the implementation is much, much faster (and a binary statically linked with a newer glibc would segfault on an older kernel). Sometimes glibc changes an existing API even without a kernel change, to make things simpler or more reliable. The old symbol with the old behaviour is preserved for compatibility with binaries linked against an old glibc, but new binaries get the new symbol, even if they might work perfectly well with the old symbols - old binaries on new systems are more important than new binaries on old systems. It turns out that Servo specifically is this last case. I downloaded a binary and checked what glibc symbols it used: Only 2.27 is newer than your glibc 2.24. The symbols requiring glibc 2.27 are: Apparently floating point math got overhauled in glibc 2.27. Looking at the glibc 2.27 announcement:
So a weird and rarely-used API got removed, and to preserve backwards compatibility, library functions using the new, simpler API got new symbols. As for the use of modern graphics hardware, isn't the goal of Servo to eventually replace Gecko? Is it intended to just drop support for anything older than Windows 10? Servo's not going to replace Gecko, no. Instead, bits and pieces of Servo are going to be grafted onto Gecko where they provide real benefit. For example, Servo's WebRender compositing/layout library is (I think) currently on by default for Firefox Nightly users on Windows 10 with particular versions of particular graphics drivers, and everybody else gets the current-gen compositing code. By the time Servo's tech becomes the standard build of Firefox, 2018 graphics tech is going to be old and crusty. The portability I'm asking for isn't anything insane like running on a PDP-11, it's that the binary releases should be easier to use than the source releases. If everyone's expected to build it themselves anyway, and the binary builds are broken, then why even release them? Might as well tell people to piss off and build it themselves if they want it so much. "Easier to use" isn't an absolute, binary quality. Servo's binaries are directly useful to a lot of people, they're less useful to people who have to acquire updated libraries to run them, they're even less useful to people who have to boot an x86_64 emulator to run them, and they're much less useful to people who only have a desert full of rocks. But you've got to draw the line somewhere. If the Servo folks felt they needed more testing on older hardware, I'm sure they'd put more effort into making their binaries more widely usable. But since they haven't, I guess they don't. And that's entirely their decision. You forget that static linking isn't the only one with security issues. How many security flaws have there been from LD_PRELOAD again? That's not strictly-speaking a problem with the idea of dynamic linking, it's a problem with a particular implementation of dynamic linking. It would be really easy to avoid LD_PRELOAD's risks by just removing that feature, but it's been kept around because LD_PRELOAD is so freakin' useful that the benefits outweigh the drawbacks. Also remember that the only thing that would need to be changed in such a scenario is the library version, it wouldn't be an update proper and wouldn't take much space to download. How do you figure? If a library has a problem on a static-linking-only OS, every binary that (directly or indirectly) uses that library needs to be replaced to get the update. The ending of the words is ALMSIVI. |
| tomman |
Posted on 19-02-04, 15:53 (revision 3)
|
|
Dinosaur
 Post: #141 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
Wow, didn't expected to found love for Discourse over here. Mailing lists are for Troo UNIX® Way graybeards (they're AWFUL for anything beyond a few messages). JS-rich message boards where "mobile first" is the paradigm for the next 10 years are for hipsters and people with more money than common sense that values "flashy things" over "getting stuff done". Once again, I find nothing wrong with phpBB and its lookalikes (actually Ikonboard-clones? I don't know what was the first message board package implementing this now-standard layout we're using right now here, but I DO remember Ikonboard was the very first I used, at the now defunct Sega Emulation Forums). There are oh so many reasons of why I despise Discourse and friends (some already exposed by sureanem on his posts): - JS abuse, leading to piss-poor performance - "Mobile-first" AKA "your computer/cellphone is too old for that!" - Infiniscroll™. In fact, I make sure to NEVER EVER visit Infiniscroll-enabled websites once I learn about their usage of this particularly abusive feature. Some "modern" messageboard solutions do allow to switch between Infiniscroll and pagination... sadly Discourse is NOT one of those. - Waste of vertical space. ONCE AGAIN, I'M NOT BROWSING YOUR MESSAGE BOARD FROM A GODDAMNED CELLPHONE! If I wanted a smaller viewport (which is someting you actually would want on modern big displays, not on 14" laptop panels), I can use this newfangled feature known as "resizable windows", of which pretty much every Real Computer™ made in the last 30 years is capable of. - Here are oh-so-many reasons to despise Discourse (make sure to read the entire thread, as it contains important background info), from a well-known former setup (they migrated to NodeBB which is more of the same unusable Javascript abominations, although the project lead devs aren't as assholes as Jeff Atwood; still I won't be registering an account there anytime soon unless they decide to switch again to a saner message board solution -I've been a lurker since their Community Server era, which was buggier than a Windows Me setup- but given the topic of that site, having a broken unusable message board is part of the charm... sadly they went over the top with their last two migrations) Things like Ikonboard/VBulletin/phpBB/ABXD/SMF/whatever hit the sweet spot for me, considering that I'm just a human looking to talk to other humans: - Sane layouts - Boards still usable without Javascript (sure, you can't format your messages except by writing yourself the tags, but aside of that you can still interact with the board) - Tracking of threads/posts you have/haven't read yet I don't need video embedding/WYSIWYG editors/Iframely/jQuery abuse or other fancy features, all I want is to interact with other human beings! But then, I'm a dinosaur, yadda yadda yadda... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-02-04, 19:39 (revision 1)
|
|
Dinosaur
Post: #143 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
Posted by CaptainJistuce Relevant Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1523701 Apparently we can't blame Mozilla this time, but the third-party AV solutions since they're MITMing your HTTPS connections in the name of "SEKURITAH!", causing Firefox to freak out when the browser notices that something is wrong with those bogus certificates inserted by said "security" products. In this case, the solution is pretty easy: get rid of said third-party AV junk, because it should not be meddling into your Secure Sockets Layer - I fail to see the bug here, as much as I despise Mozilla, they're doing what it's supposed to do this time: warning you -the user- that someone else is doing something that it should not do. Antivirus should stick to scanning files, not to deploying their poisonous tentacles into your web browser core. One more reason to stick to MSE/Defender, if you absolutely need protection - AVG has been shit since forever, and Avast stopped being a good product about a decade or so ago. Now it seems the latter owns the former, which sets the bullshittery level up to 11. Avast has already disabled their HTTPS hijacking from Mozilla products: The configuration update in both Avast and Avg (all editions) was published as "190201-06" aprox. 18:00 CET. No action from the user is required. No other browsers are affected, only https scanning in Firefox is disabled. The typical interval between virus database update checks is 4hrs. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Duck Penis |
Posted on 19-02-04, 22:04
|
|
Stirrer of Shit
Post: #14 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Posted by Screwtape No, it is possible to use a hack to make what you describe. In CSS, you can hide the box of a checkbox. You can also set the label to anything you want, such as another element. And an element can be hidden or shown if the checkbox is checked or unchecked. It's slightly idiosyncratic design, but I've never heard of it causing lag, while I have seen many JS-heavy websites have this problem. For reddit, it'd work fine. Posted by Screwtape That's a reasonable opinion. But I don't see what it has to do with discourse? You could make a phpBB theme with smaller avatars and the usernames on top. I'll admit that Discourse looks nicer if you're into that kind of design (personally, I find it soulless, but that's obviously a matter of taste). But technologically, it's atrocious. It takes serious "skill" to design a forum software that manages to cause LAG on the client side, but Discourse manages to pull it off. Posted by Screwtape No, this is just absurd. If you add in margin to make it easier to read, that's reasonable, but to add in padding so that you can clearer make out where each post ends and the next one begins while holding page down is madness. That said, don't avatars accomplish the same goal? Posted by Screwtape Almost all imageboards have text formatting - linking URLs, making quoted text green, sometimes youtube embeds and code/spoiler tags. It's true that there are slightly fewer tags, yes, but I sincerely doubt that any differences in performance would be due to that. As for the HTML, I don't know what you're talking about. Posts are clearly delineated and put into different divs, which is not technologically more advanced than whatever this board does. It would be trivial to make a stylesheet that made it look just like regular bulletin boards. I'm sure someone has done it. Posted by Screwtape In other words, there are no technological reasons a large company couldn't use phpBB? I don't know if you've been using some different features than I have, but when I go to the front page of https://discourse.mozilla.org/ there are many different categories to choose from. Sure, you get PMs when you're replied to, but phpBB has this feature too (subscriptions). (Modern imageboards have this feature as well, but it requires JS) It has the box in a different place, yes. I don't know what it improves, I just find it a nuisance because it always nags me that I shouldn't write to someone in the same thread more than thrice (I should instead send a PM? What the fuck?) and is in general finicky (for instance, sometimes the preview doesn't render) Also, you realize that the box you wrote your post in is resizeable? (Modern imageboards have this feature as well, but it requires JS, doesn't have a preview, and is a floating "window") If you click on the username in "Posted by XXXXXXX", it does precisely what you describe. (Modern imageboards have this feature as well, it does not require JS) Links forward are neat, yes. I think this forum should implement them (modern imageboards have them), would be cool and pretty easy. But there's another sacrifice you make for it as a user of one pre-baked product over another: for some unfathomable reason, you can only respond to one post at once. You can quote multiple, but this breaks the whole link business. Pasting images is also very nice, provided it's enabled. It should be noted that when most of these softwares were developed, you couldn't just allow people to upload images willy nilly, would have been to expensive with the bandwidth. But yes, it should be added. As an optional feature, that doesn't break the board if you disable JS. (Modern imageboards have this feature, in one click less than discourse, it requires JS) Necro-bump notices are nice too. It's the only feature of these modern imageboards don't have, since it's not a concept which has to be dealt with. My point here being that 90s software has received no major changes for 20+ years, and still beats discourse handily. I've never had a real forum manage to crash my browser, but discourse manages to fail at things you didn't even know were possible. I've never had a website that unintentionally managed to break basic features such as CTRL-F or scrolling, while intending to make them better. Only with Discourse. If you're comparing modern software to modern software, then compare 4chan to Discourse. It works just fine without JS, and only if you enable it you get the features. For discourse, it just gives up completely and tells you to enable it. Completely unfathomable. No, Discourse is a cancer, just like that other application that begins with disco-. It's not just not pleasant to use, it's downright unpleasant. Even a primitive forum where you have to copy paste post numbers to and fro, it still works about like you'd expect. For discourse? No such guarantees. Can't even use page down without loading times. Posted by Screwtape That's true, maybe it was a bit of an extreme example. But what about forums? I've seen plenty of technologically illiterate old people posting on various forums without much trouble. I see slightly more that could go wrong with Discourse (Your computer wasn't made during the last 18 months? You clicked some tiny button and now you're quoting someone else and you can only tell by a small icon? You "liked" a post by accident?) than phpBB ("You forgot to quote" is all I can think of, which some people do in less busy threads) Posted by Screwtape Excludes a bunch of talented people, maybe, but I'd reckon it also filters away a lot of undesirable elements. If you're using Discourse as a mailing list, you're doing something wrong I'm fairly certain. Can you even make threads by email? Posted by Screwtape Yeah, that's what I mean. If I recall correctly, you can statically link some parts and dynamically link others. Posted by Screwtape Oh. I thought the long-term goal to produce a suitable replacement for Gecko, in which case writing code which doesn't have tight couplings out the wazoo seems reasonable to me. But since it's just a prototype, you're right - the only improvements would be very slight performance improvements. Posted by Screwtape Servo. Posted by Screwtape Isn't this what standards are for? Isn't the behavior of all those functions clearly regulated in C11? Servo's not going to replace Gecko, no. Instead, bits and pieces of Servo are going to be grafted onto Gecko where they provide real benefit. For example, Servo's WebRender compositing/layout library is (I think) currently on by default for Firefox Nightly users on Windows 10 with particular versions of particular graphics drivers, and everybody else gets the current-gen compositing code. So it will drop support for it, just a few years into the future? That sounds slightly disconcerting. I mean, if it's slated for 2040 then fine, but anything earlier is kind of rude. I don't want to have to buy a new graphics card to be able to run a web browser. "Easier to use" isn't an absolute, binary quality. Servo's binaries are directly useful to a lot of people, they're less useful to people who have to acquire updated libraries to run them, they're even less useful to people who have to boot an x86_64 emulator to run them, and they're much less useful to people who only have a desert full of rocks. But you've got to draw the line somewhere. Well, that's true. If it's for internal testing, it's up to them. That said, I don't see how it could hurt to throw in a static build or two. That's not strictly-speaking a problem with the idea of dynamic linking, it's a problem with a particular implementation of dynamic linking. It would be really easy to avoid LD_PRELOAD's risks by just removing that feature, but it's been kept around because LD_PRELOAD is so freakin' useful that the benefits outweigh the drawbacks. Dynamic linking has tons of problems, LD_PRELOAD isn't the only one. I've had many issues with .so files and dependencies and handling them, I haven't ever had issues with binary sizes (note: I don't like nor understand it when they make true 31K, but it's not hardly a real issue which causes problems) or having to download a large amount of new binaries if some security issue emerges. Dynamic linking is one of those archaic technologies I really feel should go away. It solves some complete (nowadays - not so much back in the day) non-issues, and introduces many new ones.
Right. But nothing else needs to be updated. Only the binary files. It's not an update that takes any time to prepare (short of compilation time), you don't need to increase any versions or write new man pages or anything like that, you don't need to test it, just rebuild. The download is very small in itself. There's no inherent administrative burden to an update which just consists of rebuilding binaries with new libraries. Also, if you are concerned with binary sizes then switching over to musl would cut them by far more than static linking would increase them. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| JieFK |
Posted on 19-02-08, 14:43
|
|
Post: #2 of 10
Since: 10-29-18 Last post: 2016 days Last view: 1776 days |
tomman : you seem very much knowledgeable regarding Seamonkey situation, can you share your view on this IRC slice'o'discussion ?
|
| tomman |
Posted on 19-02-08, 17:07 (revision 1)
|
|
Dinosaur
Post: #146 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
It means they're unable to build release binaries (or anything at all) outside of their developer workstations (which for a product as big as a web browser, it's unfeasible if you plan to run automated tests or stuff like that). They were studying their options for rolling their own build infrastructure (they do have access to some hardware elsewhere, which is unusable as of today due to reasons), although I heard they were considering to use Azure (which now seems to give free time for opensource projects), among other things, but so far nothing is set on stone yet. However, I was completely unaware about the "de-Mozillification" of everything else (with regards to the Bugzilla access). If this becomes true... well, ouch. Anyway, here are the latest Status Meeting notes: https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2019-02-03 Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Duck Penis |
Posted on 19-02-10, 00:32 (revision 1)
|
|
Stirrer of Shit
Post: #18 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Bloody hell. I have an issue with Firefox. I try to google it. "firefox ui crash" - get information about TABS crashing, the specific opposite of the issue I have "firefox chrome crash" - and now for something completely different Couldn't they have picked a name for their browser which wasn't already an accepted technological term? It's like if I'd start to manufacture cars and call them ENGINE™ brand cars. On another note - maybe someone here can help me with my actual issue. When I use Firefox, I sometimes run out of RAM due to poorly coded web pages. This causes everything to freeze up, until Firefox offers to stop the offending script. When it's done this, I can use the current web page just fine, and click on links. However, the tab bar is broken. Can't even navigate left and right on it, let alone click tabs. And any JS alert just shows up as an empty box with "Cancel" and "OK" as options - neither of which do anything. Likewise, any other UI action is impossible: * can't refresh page, with shortcut or button * can't switch, open, or close tabs * can open plugin UI (e.g. ublock) exactly once, but the button can only enter the pressed state and not leave it * can't open menu or use back button * plugins can open new tabs but they won't load or change title bar/address bar, however tab says "New tab" * if plugins open more than one tab, both are "active", having close buttons and being white * buttons react to hover, window reacts to resizing (partially - tabs expand and contract, and wrap to some degree, but if I drag it out too far it stops pulling in new tabs from the side, leaving me with comically large tabs) * can't drag tabs out to form new windows * clicking on close button on the real active tab (see above) gives the dotted rectangle around the tab title * closing firefox is instantaneous * cookie autodelete thing triggers on close I get that I can just restart the browser, but it's a bit of a nuisance to lose all of my open tabs. Is this a known issue? It's bloody annoying, and it seems like the kind of thing which would get noticed and fixed. My gut feeling is that someone is playing fast and loose with the malloc(). It seems like the extensions and rendering and UI works, but the parts that the buttons are bound to don't. Edit: apparently, if I open another instance of firefox and close the dead one, the tabs still show up as "Switch to tab" under autocomplete, although unclickable. Truly a mystery. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| Nicholas Steel |
Posted on 19-02-10, 06:55 (revision 1)
|
|
Post: #108 of 426
Since: 10-30-18 Last post: 499 days Last view: 14 days |
What are all your Web Extensions & plugins? What anti-virus? AMD Ryzen 3700X | MSI Gamer Geforce 1070Ti 8GB | 16GB 3600MHz DDR4 RAM | ASUS Crosshair VIII Hero (WiFi) Motherboard | Windows 10 x64 |
| funkyass |
Posted on 19-02-10, 20:32 (revision 2)
|
|
Post: #23 of 202
Since: 11-01-18 Last post: 660 days Last view: 16 days |
this has happened to me in the past, and the only way to fix it is killall Mozilla instances. Its poor memory accounting I think. TO Be fair to Mozilla, they where calling the UI chrome long before google even had android. stick bugzilla in any bug queries for firefox. |
| nyanpasu64 |
Posted on 19-02-11, 12:10 (revision 2)
|
|
Post: #10 of 77
Since: 10-31-18 Last post: 1189 days Last view: 1116 days |
dear mozilla, i will never want to visit "123refills.net". ever. sincerely, a student of "school.example.com/class-123" ---------- they're pushing this "forced completion for popular sites" crap down my throat, and i fucking hate it. First it was Firefox on Android, now it's Firefox Desktop. I'm resorting to disabling browser.urlbar.autoFill, which stops autofill even for websites I actually visited in the past. |
